Subject: [Nea] REQ: section 7

From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Date: Mon, 26 Feb 2007 02:26:32 -0000

My comments on section 7:
1.	Section 7.1: In the NEA WG charter there's the statement,
".protocols developed by the NEA WG must be designed to accommodate emerging
technologies for identifying and dealing with lying endpoints."  Which of
the common requirements addresses what's detailed in the charter?
2.	Section 7.1, requirement C-1 :  Consider rephrasing this requirement
for clarity. For example: "NEA protocols MUST be capable of supporting
multi-round message exchanges between a NEA client and NEA server."
3.	Section 7.1, requirement C-4: This requirement is too generic and
besides the security threats outlined in the security section are not broken
down into "active" and "passive" attacks, so establishment of what
countermeasures satisfy this requirement is difficult.  Consider being
explicit in this requirement and stating exactly which active and passive
attacks need to be thwarted.  
4.	Section 7.1, requirement C-6: Does the reference to "open standards"
limit the candidate protocols to just those created by the IETF? I guess I'm
asking for the definition of open standards.
5.	Section 7.1, requirement C-8: How is "efficient" defined for NEA
protocols?  Is it about being frugal with the number of bits that need to be
exchanged?  Is it about being fast to be able to better cater to
time-sensitive environments (e.g. A VoIP phone on a 802.11i network that has
NEA enabled. You don't want a bloated protocol taking significant amount of
time on each AP roam handoff). 
6.	Section 7.2, requirement PA-9:  What are string attributes?  It's
the first time they're referenced.  Are you really saying that the
requirement for PA is that any human-readable attribute content (whether
policy, compliance, posture, etc.) use a string encoding that supports
internalization?  Moreover, is this requirement not a common requirement for
both PA and PB?
7.	Section 7.4 : Why define requirements for PT if it's not within
current NEA WG charter?

Cheers,
MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
ProCurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5557
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------   

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

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 26 Feb 2007 19:55:15 -0800

We'll get back to you on these comments.  At the moment we were looking
to discuss all the other sections first (agree on context for the
requirements.)  Thanks for your completeness! 

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
> Sent: Sunday, February 25, 2007 6:27 PM
> To: [email-masked]
> Subject: [Nea] REQ: section 7
> 
> ".protocols developed by the NEA WG must be designed to 
> accommodate emerging technologies for identifying and dealing 
> with lying endpoints."  Which of the common requirements 
> addresses what's detailed in the charter?
> for clarity. For example: "NEA protocols MUST be capable of 
> supporting multi-round message exchanges between a NEA client 
> and NEA server."
> besides the security threats outlined in the security section 
> are not broken down into "active" and "passive" attacks, so 
> establishment of what countermeasures satisfy this 
> requirement is difficult.  Consider being explicit in this 
> requirement and stating exactly which active and passive 
> limit the candidate protocols to just those created by the 
> IETF? I guess I'm asking for the definition of open standards.
> protocols?  Is it about being frugal with the number of bits 
> that need to be exchanged?  Is it about being fast to be able 
> to better cater to time-sensitive environments (e.g. A VoIP 
> phone on a 802.11i network that has NEA enabled. You don't 
> want a bloated protocol taking significant amount of time on 
> each AP roam handoff). 
> the first time they're referenced.  Are you really saying 
> that the requirement for PA is that any human-readable 
> attribute content (whether policy, compliance, posture, etc.) 
> use a string encoding that supports internalization?  
> Moreover, is this requirement not a common requirement for 
> both PA and PB?