Subject: [Nea] Comments on NEA TNC protocols

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Mon, 10 Mar 2008 07:51:29 -0700

Here are my general comments:
 
General:

*	It is not clear why we need to address the PA security now when
not all the pieces are well understood yet. Especially without a "full
picture" view of the PA and its state flow, it will be hard to determine
the best security model to be provided.  I would suggest that we focus
first in stabilizing the PA and PB constructs before we finalize or
contemplate the security aspects for the PA.  

*	It is hard to "connect" how the PA and PB will work together
given the lack of specificity or examples with particular transport
protocols.  It would be good if at least an example packet flow, from
initial discovery or publication/subscription to the PA attributes to
their completion (inclusive of both successful and unsuccessful)
transaction are provided.

*	The CMS model adapted for NEA and provided in
draft-sangster-nea-pa-tnc-security-00.txt doesn't seem to fit both the
dynamic nor the group nature of the PA.  The
draft-sangster-nea-pa-tnc-00.txt draft implies a dynamic group
relationship given the publish/subscribe model; this imposes problem for
encryption as the message recipient must be known.  Do you send multiple
messages?  Do you send to an intermediary (PB perhaps)? Is there some
other key establishment method (key server, multiparty DH,...)

For replay detection, it appears that the initial message is not
protected (this may not be a problem).  If there are multiple parties
involved in the exchange it is not clear how the nonce is generated and
validated.

Further, the addition of a capabilities discovery is eluded to in the
draft, but the details are unclear or inconsistent.  Section 2.4
mentions "The algorithm list is encapsulated within a signed CMS message
that the recipient can use to verify the authenticity and integrity of
the algorithm", but given the group nature of the PA and a discovery of
capabilities, its unclear how a signature can be imposed in the message
for proper validation if the appropriate trust anchors has not been
established.  Can other algorithms be explored beyond RSA for signing
and ECDSA for validation (these are very computationally expensive).  A
state or process flow diagram should be provided, or at minimum a
description 

*	Given the dynamic group aspect of the PA, it is unclear how key
management and key lifetimes are asserted and enforced?

*	draft-sangster-nea-pa-tnc-security-00.txt enforces the use of
certificates which may be prohibitive in some deployments.  There are
network deployments today that are not PKI "ready", nor do they have the
means and perhaps desire to enforce PKI.  The security model should
allow for such "legacy" deployments and scenarios to work as well.

*	The security mechanisms should employ NIST approved
cryptographic algorithms, SHA-1 will be deprecated by 2010 and should be
avoided if possible.

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

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 10 Mar 2008 17:46:47 -0700

Some fodder for tomorrow's discussion...  My comments are more with an
eye towards tomorrow's decision: are these good starting points not
whether they are ready for RFC ... they aren't!  Thanks for the good
discussion topics.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Nancy Winget (ncamwing)
	Sent: Monday, March 10, 2008 7:51 AM
	To: [email-masked]
	Subject: [Nea] Comments on NEA TNC protocols

	General:

	*	It is not clear why we need to address the PA security
now when not all the pieces are well understood yet. Especially without
a "full picture" view of the PA and its state flow, it will be hard to
determine the best security model to be provided.  I would suggest that
we focus first in stabilizing the PA and PB constructs before we
finalize or contemplate the security aspects for the PA.  
		 
		[PS] Not sure I follow your concern for the full
picture.  The requirements spec provides much of the high level picture
including examples and usage models for NEA.  The proposal specs were
based on that work.  We could carry some of the examples into these
specs to help clarify if the WG doesn't mind some spec bloat.  At this
point (just had the -00 drafts submitted) we probably need some time for
folks to read and hear about the new specs before saying we shouldn't
pursue something major like dropping security for PA.  We do have room
later to drop the PA security proposal if the WG believes its not needed
or not appropriate.  At this point its too soon to make such a decision
without some good dialogs occurring and understanding where the problems
lie.

	*	It is hard to "connect" how the PA and PB will work
together given the lack of specificity or examples with particular
transport protocols.  It would be good if at least an example packet
flow, from initial discovery or publication/subscription to the PA
attributes to their completion (inclusive of both successful and
unsuccessful) transaction are provided.
		 
		[PS] Both PA and PB specs talk about how they fit
together (e.g. section 2.2 of PA particularly the diagram at the top of
page 8), but we could also include an example if that helps.  Maybe we
should consider an appendix with a detailed example of PA security, PA
and PB all in use in a realistic enterprise situation.

		[PS] An instance of the protected attributes are
protected for a particular recipient.  PA and PB allow for this to be
dynamically established and the sender can dynamically learn the
capabilities of each recipient.  A sender can use a single CMS protected
attribute that is protected for multiple separate recipients or just
send multiple separately protected attributes (if thats needed).  This
is a power of CMS (e.g see section 6.2 of RFC 3852) and the PA attribute
model.  Maybe you could describe a usage where this approach won't work
so we can understand if there is a deficiency?

	[PS] Remember the nonces are included in the signed attributes
so the recipient knows the (original) sender identity.  If the attacker
is replaying a protected CMS attribute that includes the anti-replay
protection the recipient could detect this by keeping track of previous
initial nonces used (this is discussed in the spec).  If the recipient
chooses not to do this, then your correct that this might be possible.
I'm not sure this is a problem worth solving but because of the
extensibility of CMS attributes and the PA attributes we could improve
or add other freshness mechanisms to the protocol without breaking it.
Of course i'm hope to suggestions to improve the proposed one.

	Further, the addition of a capabilities discovery is eluded to
in the draft, but the details are unclear or inconsistent.  Section 2.4
	 
	[PS]  There would need to be some basis for common trust amongst
the parties.  I think this is consistent with the usage models we've
discussed in the past and in the requirements spec.  We have scope NEA
down to certain usages where I don't believe this is a problem.  Do you
have a usage model in mind that wouldn't work and that fits within our
charter?  Its not my expectation that dynamic trust establishment is in
scope for our work.  If its needed for a deployment maybe something like
the TAMP protocol could help (which also is based on CMS) but dynamic
trust establishment is extremely difficult.

	We also need some common security algorithms to pre-exist for
this to work.  Fortunately we have the mandatory to implement set in
section 2.3.2.2, 2.3.3.2 and 2.3.3.3 sections of the PA Security spec.
I would expect these sections would be closely examined to pick the
appropriate cryptographic suite but do believe that these algorithms
could be used to protect the security capability discovery (or
advertising) method proposed.  Note that this method pull heavily from
how S/MIME works (using SMIMECapabilities for those familiar with
S/MIME). 

	*	Given the dynamic group aspect of the PA, it is unclear
how key management and key lifetimes are asserted and enforced?
		 
		[PS] We should probably work through an example usage.
We should pick one that is in our scope and see how the protocols work
and where they fall short.  Note that CMS offers a variety of key
management schemes that we could adopt (see section 6.2 of RFC 3852 for
some of our options).  The current spec is based on the X.509 technique
but we could certainly add other lower-infrastructure techniques as
well.  We expected this might happen and fortunately we can leverage the
hard work that CMS has already done.

	*	draft-sangster-nea-pa-tnc-security-00.txt enforces the
use of certificates which may be prohibitive in some deployments.  There
are network deployments today that are not PKI "ready", nor do they have
the means and perhaps desire to enforce PKI.  The security model should
allow for such "legacy" deployments and scenarios to work as well.
		 
		[PS] CMS allows for other approaches to be used.  The
general approach to PA security using CMS doesn't have this limitation.
If we choose to start from this draft we could add other key management
schemes to address this valid concern. 

		[PS] See the algorithm sections mentioned above.  The
draft requires SHA-256 for this reason and states SHA-1 is effectively a
"MUST-".  This spec references and uses the new NIST algorithms and
references the new S. Turner I-D for CMS.

	  Nancy.