Subject: [Nea] Should we downgrade PA security to a SHOULD, MAY or remove it?

From: "Paul Sangster" <[email-masked]>
Date: Thu, 6 Sep 2007 14:31:04 -0700

Hopefully everyone noticed that our -04 revision was published and is 
awaiting comments from the WG.  As mentioned in my prior e-mail on
8/24/07,
we've made a significant number of changes based on comments received 
during WGLC.  We tried to address those comments but one significant
question that was not addressed relates to our requirement PA-5 below:
 
 "PA-5 The PA protocol MUST provide authentication, integrity, and 
       confidentiality of attributes communicated between a Posture 
       Collector and Posture Validator. This enables end-to-end security

       across a NEA deployment that might involve traversal of several 
       systems."
 
The question is should this requirement be a SHOULD, MAY, or removed 
entirely?  This requirement guides our selection process for the PA
protocol and currently would prevent candidate PA protocols from being
selected if they lack proper security protections.  In the past
we've discussed the overlapping requirements for security upon PA
(MUST),
PB (MAY) and PT (MUST) and in Prague this factored into our decision to
reduce PB to a MAY (instead of a MUST).  This topic is also discussed in

section 8.2 and other parts of the spec.
 
The current PA security protections were included to provide for end to
end 
(e.g. Posture Collector to Posture Validator) authentication, integrity
and
confidentiality protection of the PA attributes.  These attributes might
travel to remote 
systems hosting the posture validator that are separate from the posture

transport server thus PT protections are no longer present.  Several
folks 
have mentioned that the protection of the link between the posture
transport 
server and remote posture validator could be provided in other less
complex 
ways and so requiring a standards based PA security protocol isn't
critical 
and will just make our deliverable more difficult.  We also would need
to
specify a solution consistent with the principals of RFC 4107 which
could
be challenging.
 
We would like to request that the working group discuss whether we
should 
downgrade PA-5 to SHOULD, MAY or remove it all together.  In order
to bound the discussion we would like to conclude the discussion by 10PM
PDT
on thursday, Sept 20th (2 weeks).  This will allows the editors time to
make 
any revisions to the specification and re-submit in a timely manner so
we can
product a new I-D ready for a re-start the WGLC process.
 
Paul
_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "todd glassey" <[email-masked]>
Date: Thu, 6 Sep 2007 15:22:36 -0700

----- Original Message ----- 
  From: Paul Sangster 
  To: [email-masked] 
  Sent: Thursday, September 06, 2007 2:31 PM
  Subject: [Nea] Should we downgrade PA security to a SHOULD, MAY or remove it?

  awaiting comments from the WG.  As mentioned in my prior e-mail on 8/24/07,

  we've discussed the overlapping requirements for security upon PA (MUST),

Paul - the issue is the use model. If NEA is used across an Enterprise Architecture or multiple campus type topologies then the policy controls "MAY" want to require this end-to-end functionality. 

Likewise, if the NEA tools were used for something like Microsoft Genuine Advantage compliance, then it would definently be a MUST one would think.

The real issue is that the OPERATIONS POLICIES (OP)  will determine whether certain functions or criteria are put in place, so depending on the OP's the state of this control will changed so you need to be able to say MUST in some cases and MAY or OPTIONALLY in others.

  The current PA security protections were included to provide for end to end 
  (e.g. Posture Collector to Posture Validator) authentication, integrity and
  confidentiality protection of the PA attributes.  These attributes might travel to remote 
  systems hosting the posture validator that are separate from the posture 
  transport server thus PT protections are no longer present.  

OK so this could be a situation perhaps where a Trusted Third Party was operating the NEA master PV so it needs some tunnel to communicate with the other components of the system. I think this is 'doable' with the simple addition of a requirement "that all NEA components communicate in a secure manner" which meets Industry Security Requirements for those application's bases. This type of disclaimer means that the NEA Spec itself doesnt need to address these inter-nodal security issues IMHO.

  Several folks 
  have mentioned that the protection of the link between the posture transport 
  server and remote posture validator could be provided in other less complex 
  ways and so requiring a standards based PA security protocol isn't critical 
  and will just make our deliverable more difficult.  

The problem here isnt NEA - its the use environments which NEA is to be used in and many of them already have their own security and audit requirements. 

  We also would need to
  specify a solution consistent with the principals of RFC 4107 which could
  be challenging.

Understood - EAP is complex...

  We would like to request that the working group discuss whether we should 
  downgrade PA-5 to SHOULD, MAY or remove it all together.  

I think PA-5's status is dependant on the end use model and based therein, the existing language of its description needs to be changed to reflect that.

  In order
  to bound the discussion we would like to conclude the discussion by 10PM PDT
  on thursday, Sept 20th (2 weeks).  This will allows the editors time to make 
  any revisions to the specification and re-submit in a timely manner so we can
  product a new I-D ready for a re-start the WGLC process.

Existing:

Proposed:

 "PA-5 The PA protocol can be used in conformance with other
      tools and BCPs which will set at a policy level the requirements 
      for which components of the NEA specification are mandatory, 
      and which are optional. In all instances NEA systems rely on 
      the integrity of the underlying Network System to operate on
     and so in these instances the PA MUST provide authentication, and 
     confidentiality of attributes communicated between a Posture 
     NEA Components (Posture Collector's and Posture Validator). 
     This Integrity and confidentiality of communications may be integrated
     into NEA implementations or those implementations may rely on other
     protocols and technologies to supply those operation's features for the
     NEA suite.

    This flexibility in NEA design and deployment enables 
    end-to-end security across a NEA deployment which may 
    involve traversal of several heterogenous networks and their systems."

/TSG

  Paul

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

---

From: "Paul Sangster" <[email-masked]>
Date: Thu, 6 Sep 2007 15:33:01 -0700

Thanks you've made some good points.  I just want to re-iterate that the
goal of these protocol requirements is to state what the WG criteria
will be when selecting the PA, PB and PT protocols.  Thus if we leave
PA-5 as it currently stands, the WG must only select a PA candidate
protocol capable of providing authentication, integrity and
confidentiality protection.  Whether a deployment chooses to use those
protections is up to the deployer (assuming these features are supported
by the selected protocol).  So, if we change MUST to SHOULD then this
means the WG can consider and potentially select a PA protocol which
lacks some or all of the described security protections.

________________________________

	From: todd glassey [mailto:[email-masked]] 
	Sent: Thursday, September 06, 2007 3:23 PM
	To: Paul Sangster; [email-masked]
	Subject: Re: [Nea] Should we downgrade PA security to a
SHOULD,MAY or remove it?

		----- Original Message ----- 
		From: Paul Sangster <mailto:[email-masked]>

		To: [email-masked] 
		Sent: Thursday, September 06, 2007 2:31 PM
		Subject: [Nea] Should we downgrade PA security to a
SHOULD, MAY or remove it?

		Hopefully everyone noticed that our -04 revision was
published and is 
		awaiting comments from the WG.  As mentioned in my prior
e-mail on 8/24/07,
		we've made a significant number of changes based on
comments received 
		during WGLC.  We tried to address those comments but one
significant
		question that was not addressed relates to our
requirement PA-5 below:
		 
		 "PA-5 The PA protocol MUST provide authentication,
integrity, and 
		       confidentiality of attributes communicated
between a Posture 
		       Collector and Posture Validator. This enables
end-to-end security 
		       across a NEA deployment that might involve
traversal of several 
		       systems."
		 
		The question is should this requirement be a SHOULD,
MAY, or removed 
		entirely?  This requirement guides our selection process
for the PA
		protocol and currently would prevent candidate PA
protocols from being
		selected if they lack proper security protections.  In
the past
		we've discussed the overlapping requirements for
security upon PA (MUST),
		PB (MAY) and PT (MUST) and in Prague this factored into
our decision to
		reduce PB to a MAY (instead of a MUST).  This topic is
also discussed in 
		section 8.2 and other parts of the spec.

	Paul - the issue is the use model. If NEA is used across an
Enterprise Architecture or multiple campus type topologies then the
policy controls "MAY" want to require this end-to-end functionality. 
	 
	Likewise, if the NEA tools were used for something like
Microsoft Genuine Advantage compliance, then it would definently be a
MUST one would think.
	 
	The real issue is that the OPERATIONS POLICIES (OP)  will
determine whether certain functions or criteria are put in place, so
depending on the OP's the state of this control will changed so you need
to be able to say MUST in some cases and MAY or OPTIONALLY in others.

		The current PA security protections were included to
provide for end to end 
		(e.g. Posture Collector to Posture Validator)
authentication, integrity and
		confidentiality protection of the PA attributes.  These
attributes might travel to remote 
		systems hosting the posture validator that are separate
from the posture 
		transport server thus PT protections are no longer
present.  

	OK so this could be a situation perhaps where a Trusted Third
Party was operating the NEA master PV so it needs some tunnel to
communicate with the other components of the system. I think this is
'doable' with the simple addition of a requirement "that all NEA
components communicate in a secure manner" which meets Industry Security
Requirements for those application's bases. This type of disclaimer
means that the NEA Spec itself doesnt need to address these inter-nodal
security issues IMHO.

		Several folks 
		have mentioned that the protection of the link between
the posture transport 
		server and remote posture validator could be provided in
other less complex 
		ways and so requiring a standards based PA security
protocol isn't critical 
		and will just make our deliverable more difficult.  

	The problem here isnt NEA - its the use environments which NEA
is to be used in and many of them already have their own security and
audit requirements. 

		We also would need to
		specify a solution consistent with the principals of RFC
4107 which could
		be challenging.

		We would like to request that the working group discuss
whether we should 
		downgrade PA-5 to SHOULD, MAY or remove it all together.

	I think PA-5's status is dependant on the end use model and
based therein, the existing language of its description needs to be
changed to reflect that.

		In order
		to bound the discussion we would like to conclude the
discussion by 10PM PDT
		on thursday, Sept 20th (2 weeks).  This will allows the
editors time to make 
		any revisions to the specification and re-submit in a
timely manner so we can
		product a new I-D ready for a re-start the WGLC process.

	Existing:
	 
	 "PA-5 The PA protocol MUST provide authentication, integrity,
and 
	       confidentiality of attributes communicated between a
Posture 
	       Collector and Posture Validator. This enables end-to-end
security 
	       across a NEA deployment that might involve traversal of
several 
	       systems."
	 
	Proposed:
	 
	 "PA-5 The PA protocol can be used in conformance with other
	      tools and BCPs which will set at a policy level the
requirements 
	      for which components of the NEA specification are
mandatory, 
	      and which are optional. In all instances NEA systems rely
on 
	      the integrity of the underlying Network System to operate
on
	     and so in these instances the PA MUST provide
authentication, and 
	     confidentiality of attributes communicated between a
Posture 
	     NEA Components (Posture Collector's and Posture Validator).

	     This Integrity and confidentiality of communications may be
integrated
	     into NEA implementations or those implementations may rely
on other
	     protocols and technologies to supply those operation's
features for the
	     NEA suite.
	 
	    This flexibility in NEA design and deployment enables 
	    end-to-end security across a NEA deployment which may 
	    involve traversal of several heterogenous networks and their
systems."

	/TSG

		Paul

________________________________