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.
- 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,...)
[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?
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.
[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
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
[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.
- The security mechanisms should employ NIST
approved cryptographic algorithms, SHA-1 will be deprecated by 2010 and
should be avoided if possible.
[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.
