Comments for TNC SCAP Messages for IF-M
Public review comments received for TNC SCAP Messages for IF-M Specification, Version 1.0, Revision 16.
Review Period: Ends on January 15, 2013
Those wishing to be added to the email reflector to received specification comments as they arrive should contact [email protected]
Comments Received:
| Jean Dube, Haivision Network Video; 10/9/2012, 8:16 a.m. PDT | ||
| I am not familiar with the TNC specification suites and got here following a SCAP path. So maybe there are justifications of my concern in other specifications of the suite.I found strange to use MD5 in a 2012 protocol assessing the security of systems. Even if the role of MD5 in this case does affect security, implementations of this protocol will most likely need to embed MD5 since FIPS 140-2 cryptographic modules will not be able to provide this hash since MD5 has been banned for some time. Isn’t it inconsistent to check that a system does not use MD5 using a protocol that uses it?I see no provision in the spec (I must admit that I did not studied in details) for the use of other hash. Not that even SHA-1 is close to its end of life. | ||
| Response: Charles Schmidt, The MITRE Corporation; 10/9/2012, 2:05 p.m. PDT | ||
| I do not believe there was any particular reason for selecting MD5 for this role. (I might have selected it for having a smaller output size, but clearly my research was incomplete, as you note.) I’ll make sure those references get replaced with a more appropriate algorithm. I’ll want to consult with people who have more experiencewith modern hash algorithms than I, but maybe SHA-256 would work. | ||
| R. David Oliva; 10/11/2012, 9:07 a.m. PDT | ||
| R. David’s comments available here. |
||
| Response: Charles Schmidt, The MITRE Corporation; 10/11/2012, 10:28 a.m. PDT | ||
| Thanks a bunch for the great comments. These are great points and we’ll make sure to address them. I’m a bit confused on a couple of them, though. If you could clarify that would be great. #5 – “The use of OCIL is not explained” -Are you saying it isn’t clear how OCIL would fit into a NAC scenario? If so, then I agree that I think its use in NAC is unlikely – I don’t imagine most organizations will ask users to fill in surveys prior to getting network connectivity. That said, for subsequent assessment (i.e., assessment of an endpoint at some time after the endpoint has been granted network access) I can imagine multiple uses for OCIL. For example, one could use OCIL to verify users are knowledgeable with regard to enterprise security policies, or even use it for a data call for connected users.
In general, we tried to keep this specification agnostic as to how the actual SCAP content would be used in an enterprise, since this has been the traditional purview of existing SCAP tools. Instead, we tried to focus just on how to transmit the SCAP content (or the gist of it, in the case of summary results) between TNC devices. So, to your comment, are you suggesting that it might be useful for the spec to go into some sample scenarios of how various SCAP standards might be used, or were you doubtful of the utility of OCIL in this scheme in particular? #7 – Similar to the previous comment – is there a specific point about CPE dictionaries that you think the protocol implementers need to know. I had envisioned that the dictionary from which the CPE elements in a content stream were taken would not be of import to the IMC-IMV. Regarding the statistical discussion, I think your analysis only holds if the endpoint’s compliance with a given test is determined randomly, which should definitely not be the case. I would imagine that a reasonable set of NAC questions could be like: 1) Is the AV on, 2) is the firewall on, 3) Is the OS at least at patch level X, 4) is the web browser at least at patch level Y, 5) Is the company’s activity monitoring agent installed and running. In this case, an absolute result seems very reasonable to me. Have I gotten hung up on some detail and missed your point on this? I am pretty sure I understand your other points and will make sure they get addressed in the revised spec. Thanks again for the great comments. I really appreciate your insight here. |
||
| Clifford Kahn, Juniper Networks; 1/3/2013, 2:34 p.m. PST | ||
| Clifford Kahn’s comments available here. | ||
| Adam W. Montville, Tripwire; 1/4/2013, 6:14 a.m. PST | ||
| I have read the document available at http://www.trustedcomputinggroup.org/resources/tnc_scap_messages_for _ifm and have the following comments. Please note that comments are not based on attempted implementation or stringent specification simulation.* Section 2.5: “Connectivity to the Internet.” At another point in the document, it is recommended that necessary information be provided to the IMC by the IMV, which would alleviate this potential problem, but what were to happen if certain data dictionaries were unavailable to the IMC? Dos the SCAP Error message set accommodate such a condition? For example, if a CCE Identifier is referenced, but not provided in an “official” CCE dictionary (or at least from an official CCE dictionary). * At many locations in the document the term “assessment instruction” or its plural variant (“assessment instructions”) is used. What, exactly, is an “instruction” in this context? Perhaps I missed it, but without explicit understanding, it’s difficult to say whether we’re talking about an XCCDF Rule or a Check in the checking system. Perhaps it’s both depending on the context (SCAP 1.2, if I remember correctly, accommodates OVAL-only content). * Related to my first comment is one that I noted in section 4.3.4 (the second paragraph after Figure 5 – though the location is not important). My concern here may be unwarranted, but if there are certain deviations the IMC must take from the SCAP specification, what consequence might that have for a vendor validation? It seems that a vendor that must find a URI online when such content is unavailable locally would necessarily need to raise an error condition should the IMV not provide that data – this would be in support of achieving and maintaining validation. * I recommend inclusion of a glossary.Otherwise, this seems like a very complete document. Happy to have read it. Also, I do note that specific error conditions might address at least two of my concerns above. The most important thing next to appropriate functionality is to ensure that implementers are not caused additional expense in SCAP validation (i.e. additional development/design considerations, testing costs, validation lab costs, etc.). Perhaps a better way to put it is this: I should be able to create an |
||