Re: [secdir] Secdir review of draft-ietf-nea-pa-tnc-04.txt

["Paul Sangster" <[e-mail]>]

 

> -----Original Message-----
> From: Tobias Gondrom [mailto:[e-mail]] 
> Sent: Tuesday, October 06, 2009 9:33 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]; 
> Paul Sangster
> Subject: Secdir review of draft-ietf-nea-pa-tnc-04.txt
> 
> I have reviewed this document as part of the security 
> directorate's ongoing effort to review all IETF documents 
> being processed by the IESG.
> These comments were written primarily for the benefit of the 
> security area directors. Document editors and WG chairs 
> should treat these comments just like any other last call comments.

Thanks for the review, some comments and questions below...

> 
> 
> First and for all: from the security perspective, I see a 
> major issue which is discussed in my last point #5. The 
> remaining issues are minor comments: 
> 
> 
> 0. This draft is closely linked to one other work-in-progress 
> draft draft-ietf-nea-pb-tnc-05 which is also linked as 
> normative references. draft-ietf-nea-pa-tnc MUST ONLY proceed 
> if the normative referred doc can advance as well. 

Agreed, this is what the working group had in mind as well.

> 
> 
> 1. COMMENT: section 4.1, page 17:
> Question: could Bit 0 (0x80), the NOSKIP flag, result in a 
> kind of Denial of Service vulnerability: client sneaking in 
> on message in a whole collection and thus disabling the 
> evaluation of all, although all prerequisites for a network 
> endpoint to be serviced are fulfilled?

Not sure I understand the question.  The Posture Validator (on the NEA
Server) would have policy that dictates what information it must receive
from the client.  If the client chose to send less attributes (e.g.
privacy filter) or unsupported attributes were sent with NOSKIP, this
could just prevent the endpoint for gaining access to the requested
resource (e.g. network access) or asset.  Is this the case you had in
mind?  If so, it doesn't seem to be a security threat just an issue with
the NEA client's configuration.

> 
> 
> 2. COMMENT: section 4.1. paragraph "PA-TNC Attribute Length"
> Question: maybe the paragraph would want to state what 
> happens if the length is incorrect: recommendation would be 
> that in such a case the length should be considered as a hint 
> and parsed for the begin of the next messages and the 
> following messages can (SHOULD?) still be parsed and interpreted.

Section 4.1 pretains to the Attribute Header TLV, so we could beef up
the discussion of *if* the recipient is aware that the length field is
incorrect what it should do.  We suggest that it should send an error
attribute like it does when its known to be too small.  Incorrect length
values can cause some real problems so its best to error out if one is
detected.  For example, variable length attributes without another
embedded/correct length field or unknown attributes can't be skipped if
the length isn't known.

> 
> 
> 3. COMMENT: 4.2.6. Port Filter
> considering potential size limits for messages, might it be a 
> good idea to allow ranges of port numbers (e.g. B 220-8000) 
> instead of a (potentially larger) list of port numbers?

We believe we can support port filter lists with the current syntax.  In
order to help send less traffic we allow for the sender to either send
blocked ports or allowed ports using the B flag.  Frequently the
endpoint only allows a very small number of allowed inbound ports so the
report is very short since everything else is blocked.

> 
>  
> 4. COMMENT:  4.2.11. Forwarding Enabled
> just a hinge: if forwarding is enabled, might it be helpful 
> to add a qualifier about the allowed forwarding addresses, so 
> that the server can determine whether this is acceptable 
> within the policy. (forwarding to addresses within the same 
> network subunit may be acceptable?)

This attribute is to detect forwarding of network traffic across network
interfaces (e.g. not allowing endpoints VPNing into network to have
another connection to Internet).  The most common customer request is to
not allow bridging/routing traffic across networks at all and we wanted
to avoid trying to express forwarding policy inside this attribute.  If
a need to be more specific is raised we could add an additional
attribute to cover this case using the attribute extensibility model.

> 
> 
> 5. DISCUSS: 5. Security Consideration:
> This section mentions that "PA-TNC security protocols are 
> described in separate specifications which layer upon the 
> base PA-TNC protocol described in this specification."
> Actually, I have not seen this security protocol on the WG 
> page and am quite worried about this. (I found an old 
> 00-version that expired August 2008, I have not reviewed its 
> content.) PA-TNC can disclose a lot about the security 
> properties of an endpoint and actually also of a server 
> landscape. Therefore it MUST be ensured that the requests and 
> responses are made by authorized parties (and e.g. not by any 
> network the client stumbles upon). In fact for the protocol 
> both parties must be authenticated and authorized. Sections 
> 5.2.1. to 5.2.6 describe nicely a variety of threats if this 
> is not fulfilled. And this is correct. But the draft is short 
> on how to prevent these risks. 

We will update the sections mentioning the security protocol and
highlight better how/when PT security is addressing a particular threat.
Based upon the trust model (in section 5.1 and the use cases in scope
for the NEA charter - no remote Posture Validators or Posture
Collectors), the NEA WG opt'ed to not pursue a PA-TNC security protocol.
We will add text explaining this to the next revision.

> 
> Section 5.1. and 5.2. recognize the importance of trusted 
> counterparties in the communication, but seem to ignore that 
> PA-TNC SHOULD NOT (or even MUST NOT) be used without 
> mechanisms allowing this bi-lateral trust. 
> 
> To ensure interoperability the authentication mechanism 
> SHOULD use common standard mechanisms and could include them 
> in this document. (even if it would be just as simple as e.g. 
> use TLS two-party authentication, or other means deemed 
> appropriate by the WG). 

The RFC 5209 discusses these requirements in section 7.2 including:

"   PT-2 The PT protocol MUST be capable of supporting mutual
         authentication, integrity, confidentiality, and replay
         protection of the PB messages between the Posture Transport
         Client and the Posture Transport Server."

This requirement will guide the selection of NEA standard PT protocols
(the next working group work item).  Because of this requirement, PA is
able to be confident that such security mechanisms exist in the PT
protocol.


> 
> Summarizing: the draft should add one or more of the following: 
> 1.A common authentication mechanism to be used.
> 2.That PA-TNC MUST use an underlying protocol that ensures 
> two-side authentication and evaluate the the authentication 
> data to decide on authorization of disclosure of data. 
> 3.PA-TNC is only valid in conjunction with the mentioned 
> PA-TC security protocol which is not specified, yet?

See above

> 
> Probably the easiest solution would be to add a section to 
> the security considerations: 
> "PA-TNC MUST use means of two-side authentication to ensure 
> the required underlying trust relationship between both 
> parties is not exploited. <...continue with more text...>"

PA-TNC will be able to determine the authenticated identities passed up
the stack by PT.  This PT strong authentication will be used to
establish the trust relationship and is the basis for several policy
decisions by the NEA Client (e.g. privacy, trust).  Since PA-TNC is
enveloped in the PT protocol (via the PB protocol) it will be bound to
PT's trust decisions using the peer's identity.

> 
> Please excuse me for being that strong about it, but I can 
> lterally imagine dozens of potential security exploits if 
> this would be implemented without good underlying security 
> mechanisms. And from my understanding the current draft does 
> not "REQUIRE" underlying security, which worries me. I like 
> the draft's concept, but believe it must add a bit more 
> towards secure use to be released. But maybe I just missed something? 
 
Understandable and of course we are concerned about such attacks as
well.  The NEA architecture forces PA-TNC to operate on top of PB and PT
where the security protections are present.  PA by requirement C-4 MUST
not be aware of what PT is running below but it can leverage the PT
authenticated identities with confidence since PT is required to support
strong security in requirement PT-2.

> Kind regards, Tobias
> 
> 
> Tobias Gondrom
> email: [e-mail]
> 
>