attachment

Randy, The suggested mandate was for a cryptographically secure hash, which is satisfied by either SHA256 or SHA512.  Otherwise, collisions will reduce the utility of Configuration State. dhw David H. Whitehead Development Engineer Lexmark International, Inc. 859.825.4914 davidatlexmarkdotcom <table width=100%> <tr valign=top> <td width=40%>Randy Turner <rturner@amalfisystems.com> 08/15/08 02:13 PM <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>To</div> <td>Dave Whitehead <david@lexmark.com> <tr valign=top> <td> <div align=right>cc</div> <td>ids@pwg.org <tr valign=top> <td> <div align=right>Subject</div> <td>Re: IDS> DRAFT: IETF NEA proposal</table> <table> <tr valign=top> <td> <td></table> </table> Hi Dave, In the proposal, I just indicated that the "value" is a hash - it's currently 32 bytes which only allows for a 256-bit hash. If we mandate that it should be able to hold a SHA-512 as well, we'll have to double it's length.  I think just getting agreement for the existence of the attribute is the goal, we can flex the size of the field once we have consensus on the acceptance of the attribute. I agree with your comment about which values to include in the hash, but from a protocol perspective, the mechanisms would work pretty much the same way. Even though a vendor could allow customers to indicate which parameters are included in the hash, the "management tool in the sky" would have to know which parameters make up the hash, on a per-device basis, in order to potentially remediate the situation. Given this constraint, I think vendors should supply a factory default set of params that make up the hash, a set that makes sense in the majority of cases, and allow customers to override this, provided they "sync up" their remediation infrastructure with the same info... Randy On Aug 15, 2008, at 10:31 AM, Dave Whitehead wrote: Randy, Looks good.  Two comments about Configuration State: 1>  We should mandate the use of a cryptographically secure hash function (SHA256/512) 2>  Vendors provide the set of available configuration items but the customer selects which items to include in the hash -- some they care about, some they don't. David H. Whitehead Development Engineer Lexmark International, Inc. 859.825.4914 davidatlexmarkdotcom <table width=100%> <tr valign=top> <td width=40%>Randy Turner <<a href=mailto:rturner@amalfisystems.com>rturner@amalfisystems.com</a>   Sent by: <a href="mailto:owner-ids@pwg.org">owner-ids@pwg.org</a> 08/15/08 04:02 AM <td width=59%> <table width=100%> <tr valign=top> <td width=23%> <div align=right>To</div> <td width=76%><a href=mailto:ids@pwg.org>ids@pwg.org</a> <tr valign=top> <td> <div align=right>cc</div> <td> <tr valign=top> <td> <div align=right>Subject</div> <td>IDS> DRAFT: IETF NEA proposal</table> <table width=100%> <tr valign=top> <td width=50%> <td width=50%></table> </table> <tt>Hi All,</tt>   <tt>Please read the attached RTF and provide any feedback you may have...</tt>   <tt>Please excuse the VERY simple, raw formatting I'm using - this has to be</tt> <tt>in the simplest ASCII text form possible for eventual emailing to the</tt> <tt>NEA</tt> <tt>mailing list.</tt>   <tt>For now, just concentrate on the content :) :)</tt>   <tt>Thanks!</tt> <tt>Randy</tt>   [attachment "draft-nea-proposal.rtf" deleted by Dave Whitehead/Lex/Lexmark]