From nea-bounces@ietf.org Fri Feb 16 14:41:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8xG-0001KH-F6; Fri, 16 Feb 2007 14:41:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8xF-0001KB-82 for nea@ietf.org; Fri, 16 Feb 2007 14:41:13 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI8xB-0004L8-L5 for nea@ietf.org; Fri, 16 Feb 2007 14:41:13 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 0B71F38C3C1 for ; Fri, 16 Feb 2007 11:41:09 -0800 (PST) X-AuditID: d80ac287-9dae7bb000007e48-6e-45d608d45ac0 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id D0756348003 for ; Fri, 16 Feb 2007 11:41:08 -0800 (PST) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HI8xA-00083X-O0 for nea@ietf.org; Fri, 16 Feb 2007 11:41:08 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.10]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Feb 2007 11:41:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Feb 2007 11:41:07 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A025053EB@SVL1XCHCLUPIN01.enterprise.veritas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working towards -01 draft: call for comments and schedule Thread-Index: AcdSAmclqxn14MhbRe66G7q8Y/t5iw== From: "Paul Sangster" To: X-OriginalArrivalTime: 16 Feb 2007 19:41:08.0525 (UTC) FILETIME=[679F3DD0:01C75202] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [Nea] Working towards -01 draft: call for comments and schedule X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1071367648==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1071367648== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75202.677E8CAC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75202.677E8CAC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So far their have been a number of good discussions on the -00 reqs draft; thanks to those who took the time to participate. It is our hope to get even broader participation so we can better understand where consensus=20 exists and where issues remain. We wish the encourage more WG members to share their review of the draft and provide their constructive feedback. Knowing what sections you believe are going in the right direction=20 and those that need more focus (specifically what issues exist) will=20 help us create a better spec and avoid changing something that many people=20 believe should remain in the spec. =20 On 1/10 the WG chairs requested that we focus our comments on the initial 5 sections and to break up our e-mail comments by section or topic using descriptive subject lines. We would like to continue this practice but=20 also encourage discussion of the Use Case (section 6), Security=20 Considerations (section 8) and Privacy Considerations (section 9) sections. This means we're encouraging comments on the entire draft except section 7=20 allowing us to have a common understanding of the context for the=20 requirements before nailing down the specific requirement wordings. =20 The design team is working towards a goal of submitting the -01 revision by 3/2 (ahead of the Prague I-D cut-off.) Our hope is -01 will be published=20 early enough to allow additional discussion on the alias before the NEA=20 WG meeting. In order to make this schedule we would like to request a 2/24=20 12PM (noon) PST cut-off for comments on -00 so we can update the spec in time. Additional or unresolved discussions of comments at that time will=20 be considered for the -02 revision. =20 Paul ------_=_NextPart_001_01C75202.677E8CAC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So far their have been a number of good = discussions=20 on the -00 reqs draft;
thanks = to those=20 who took the time to participate.  It is our hope to get
even = broader=20 participation so we can better understand where consensus
exists and = where=20 issues remain.  We wish the encourage more WG members
to share = their=20 review of the draft and provide their constructive
feedback.  = Knowing=20 what sections you believe are going in the right direction
and those = that=20 need more focus (specifically what issues exist) will
help us create = a=20 better spec and avoid changing something that many people
believe = should=20 remain in the spec.
 
On 1/10 the WG chairs requested that we = focus our=20 comments on the initial 5
sections and to break up our e-mail = comments by=20 section or topic using
descriptive=20 subject lines.  We would like to continue this practice but =
also=20 encourage discussion of the Use Case (section 6), Security =
Considerations=20 (section 8) and Privacy Considerations (section 9) sections.
This = means we're=20 encouraging comments on the entire draft except section 7
allowing = us to=20 have a common understanding of the context for the
requirements = before=20 nailing down the specific requirement wordings.
 
The design team is working towards a = goal of=20 submitting the -01 revision
by 3/2 (ahead of the Prague I-D = cut-off.) =20 Our hope is -01 will be published
early enough to allow additional=20 discussion on the alias before the NEA
WG meeting. In order to make = this=20 schedule we would like to request a 2/24
12PM (noon) PST cut-off for = comments on -00 so we can update the spec in
time.  Additional = or=20 unresolved discussions of comments at that time will
be considered = for the=20 -02 revision.
 
Paul
------_=_NextPart_001_01C75202.677E8CAC-- --===============1071367648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1071367648==-- From nea-bounces@ietf.org Sun Feb 25 21:24:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVWo-00046h-Dr; Sun, 25 Feb 2007 21:23:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVWm-00046W-IC for nea@ietf.org; Sun, 25 Feb 2007 21:23:48 -0500 Received: from ccerelbas02.cce.hp.com ([161.114.21.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLVWh-0004hC-5t for nea@ietf.org; Sun, 25 Feb 2007 21:23:48 -0500 Received: from G3W0060.americas.hpqcorp.net (g3w0060.americas.hpqcorp.net [16.232.1.19]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id CB1073439F for ; Sun, 25 Feb 2007 20:23:42 -0600 (CST) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by G3W0060.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 02:23:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Feb 2007 02:23:36 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110113C552@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: REQ: sections <= 2 Thread-Index: AcdZTR2e0Qu1mxa1QhSnHu644vWgWw== From: "Sanchez, Mauricio (ProCurve)" To: X-OriginalArrivalTime: 26 Feb 2007 02:23:42.0997 (UTC) FILETIME=[2286EC50:01C7594D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Subject: [Nea] REQ: sections <= 2 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0367782685==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============0367782685== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_011A_01C7590A.108D01D0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_011A_01C7590A.108D01D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My comments/questions on sections less than or equal to two: General NITs 1.There seem to be some non-standard control characters present in the document. For example, in section 5.3 the usage of "nouns" in the second sentence shows up incorrectly. 2.Some sections of the document refer to "vendor-defined" attributes while other refer to "vendor-specific" attributes. Isn't the term "vendor-specific" more widely used in other IETF efforts versus the "vendor-defined" term? If so, I suggest we change all references of "vendor-defined" to "vendor-specific." 3.Why are "core" attributes not called "standard" attributes? After all, they're just the attributes that will be standardized by NEA WG. To me calling them "standard" attributes is a more intuitive label than "core." 4.Have IETF writing styles changed such that all terms defined in the terminology section need to be capitalized? If so, then there are instances where this guideline are not followed (e.g. the term 'reference model' is not capitalized in abstract section vs. rest of document). IMHO, extreme usage of capitalized terms, as is the case with this document, detracts from the readability. Section 2 specific comments 1. How exactly do policy attributes differ from posture attributes? It's unclear to me because of the claim in the definition of policy attributes that states that policy attributes can be used to establish compliancy without divulging posture information. Isn't the exchange of policy and compliance attributes in fact a form of posture information exchange. Cheers, MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- ------=_NextPart_000_011A_01C7590A.108D01D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDIyNjAyMjMzNlowIwYJ KoZIhvcNAQkEMRYEFL1if5SKIhB3xNwNqegvz3jKVfFwMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgCouTVAGJhAqfGRu0Jsn0nXLnrjzfOoL38Jk4fWIZXezuMkKAZc3tnM2naZcQaZL xnHrlVHlUAMPeQVlg99ET4llAPB0Kut3YRBHgUrj3wUB0CsRL2TZI70VWd+1Nf6is+HZJyaB7ocN pCPespqsE48q9N58BC8jR+vEXZx0M+lWAAAAAAAA ------=_NextPart_000_011A_01C7590A.108D01D0-- --===============0367782685== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============0367782685==-- From nea-bounces@ietf.org Sun Feb 25 21:24:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVXp-0004Ku-QI; Sun, 25 Feb 2007 21:24:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVXp-0004KE-EO for nea@ietf.org; Sun, 25 Feb 2007 21:24:53 -0500 Received: from ccerelbas02.cce.hp.com ([161.114.21.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLVXj-0004nZ-Re for nea@ietf.org; Sun, 25 Feb 2007 21:24:53 -0500 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.81.1.59]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 9616934066 for ; Sun, 25 Feb 2007 20:24:47 -0600 (CST) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 20:24:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Feb 2007 02:24:44 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110113C553@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: REQ: Section 5 comments Thread-Index: AcdZTUcDOBr2jfMtQ6a6RDSRtgZTNA== From: "Sanchez, Mauricio (ProCurve)" To: X-OriginalArrivalTime: 26 Feb 2007 02:24:47.0158 (UTC) FILETIME=[48C51D60:01C7594D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Subject: [Nea] REQ: Section 5 comments X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1855965246==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============1855965246== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_011F_01C7590A.38F47B80"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_011F_01C7590A.38F47B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Several comments/questions about section 5 [Reference Model]: 1. Meta-comment: The model seems to assume that an endpoint consists of only one processing entity (OS, hardware, etc.). It's unclear how the model and the adjunct requirements may need to get modified in light of rising popularity in system virtualization. For example, it likely that multiple posture broker clients and posture transport clients will exist on single hardware system that's been virtualized into multiple systems. I'd say additional thought is necessary in this area or we just punt and explicitly say that it's out of scope at this time. 2. Meta-comment: Section 9 describes several suggestions on how to introduce user facilities to manage privacy. In that section there's no specific guidance on which components should implement the suggested privacy enhancements. If not in section 9, wouldn't it be useful to assign the privacy enhancements to the model/components described in section 5? For example, I could envision seeing the posture collectors and posture broker client sharing responsibilities in proving a user the necessary UI and privacy policy management capabilities described in section 9. 3. Meta-comment: The model describes the existence of protocols between like layers (e.g. posture collector <--PA--> posture validator, posture broker client <--PB--> posture broker server), but provides no description as to what happens between different layers (posture collector <-> posture broker). I suspect that there's an unwritten assumption that different layers may communicate using APIs. If so, I suggest that at a minimum there be some suggestion on how different layers may be communicating (e.g. APIs) and noting that such work is out of scope for the current WG charter (and IETF in general). Side note: Section 5.1.2.2 states that validators may be physically remote to the server. Doesn't this particular situation give rise to yet another protocol for the NEA model to denote? I can imagine the existence of a PV (Posture Validator) protocol between a remote posture validator and a posture broker server. Even though the current WG charter precludes working on any protocol other than PA and PB, we should nonetheless strive for completeness in the description of the model. 4. Meta-comment: The document introduction (section 1.0) describes the existence of an enforcement entity to enforce the final admission decision. Although I understand that mechanisms and protocols for enforcement are out of scope, shouldn't the NEA model diagram and description at least acknowledge that an enforcement entity exists? There should be a general goal of having a comprehensive ENA model, even if complete treatment of all components and protocols are not currently within NEA charter. 5. Section 5.0: Discussion of reference model includes statement: "This model is provided to establish a context for the discussion of requirements and may not directly map to any particular product or deployment architecture." This statement seems to contradict the statement made in the abstract that the NEA reference model is based on the models used by CNAC, NAP and TNC. 6. Section 5.1.1.1, last paragraph: From an interoperability perspective NEA should evaluate mandating a minimum amount of functionality so as to improve the odds of interoperable implementations. Or at a minimum there should be some form of signaling introduced into the protocol to provide for component capability advertisement. 7. Section 5.1.1.2, first paragraph, second sentence: "...forwarding the request to the appropriate Posture Collectors." This sentence sounds like a request always goes to multiple collectors. I don't believe this is always the case, or is it? 8. Section 5.1.1.2, first paragraph, third sentence: "The Posture Broker Client also multiplexes the responses from the Posture Collector..." This sentence doesn't acknowledge that there may be one or more posture collectors. Consider changing to "...multiplexes the responses from Posture Collector(s)..." 9. Section 5.1.1.3 mentions that there may be more than one posture transport client on an endpoint. I suggest updating the diagram of the model detailing this fact (e.g. add "(1...n)" to posture transport client block as was done for posture collector). Furthermore, it'd be useful to describe why multiple transport clients may be necessary. 10. Section 5.1.2.1 mentions that a posture validator may be located on a separate server from the posture server. It goes on to say that the server may have to with both local and remote validators. One can assume that in the instance 11. Section 5.1.2.2 describes as one of the roles being, "Communicating with remote Posture Validators and providing cryptographic protection for this communication." It's unclear to me what this exactly means. The broker server doesn't have any direct relationships with a posture validator, or does it? Furthermore, it's not clear at what level the cryptographic protection is being provided. In section 5.1.1.3 (about posture transport client) it state clearly that its role is to protect the message dialog. I suggest the same level of clarity for server broker's role. 12. Section 5.1.2.2 - Is it not the role of the posture broker server to also establish the overall compliance decision for an endpoint? Currently the document only assigns the generation of the global posture decision. If not the broker server, which component generates the overall compliance decision? Or is the global posture decision in fact the compliance decision? I'm confused. 13. Section 5.1.2.3 - Why may there be more than one posture transport server in a particular NEA server? If there are truly multiple posture transport servers, then the NEA model diagram should be updated to reflect this possibility. See comment #8. 14. Section 5.1.2.3 - The statement "Providing cryptographic protection for Posture information." is not as clear as the one used for the posture transport client. For the posture transport client the described role is protection of message dialog. It's probably the same for the transport server and should be designated as such in the document. 15. Section 5.3.1 - I sense there is at some level some relationship between the attributes sent by a NEA server (i.e. requests) and those sent by a NEA client (i.e. responses). For example, isn't it the case that request attributes always and only elicit posture attributes as a response? Likewise, couldn't the same be said of policy attributes and compliance claim attributes? If so, it may be useful to highlight these relationships to make the protocol easier to understand. 16. Section 5.3.2 - It's unclear to me to what level the remediation attributes will get defined. On one hand the intro to this section (5.3) states that NEA WG will define a standard set of attributes. By the same token other parts of the document (e.g. section 3.1 - scope) state the standard protocols for remediation are out of scope. In defining remediation attributes are we not inadvertently defining a standard protocol for remediation? NITS a. Misplaced period in last sentence of section 5. [Reference model]. Period goes outside parenthesis bracket. b. Misplaced commas and periods in first sentence of 5.1.1.1 c. Misplaced period in last sentence of second paragraph of section 5.1.1.1. Same disposition as NIT 3a. d. Missing period on second bullet of section 5.1.1.2 e. Why is Message Dialog capitalized? See comment 7a. f. Change "Posture Transport Clients" to "Posture Transport Client" in section 5.1.1.3, first paragraph, last sentence. -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- ------=_NextPart_000_011F_01C7590A.38F47B80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDIyNjAyMjQ0NFowIwYJ KoZIhvcNAQkEMRYEFGU+LwNcFriEVI+mE9HcFSXFIgssMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgMnMqRODDYjL0Ea1XfB1kh8PzgmfuQZ2jlFnx0x8heTmY8HOC5wJBrJAWMS/COUh d4hF0X/p0L6rrtUns2ZYcVdUAmmmPFQf3Qv17OcMfEFEIMe9nlQLz0VbgBGRien+isr9hhokYNW7 UDtcd0NfFIHAiIuWsnE2hU519fqFd1NIAAAAAAAA ------=_NextPart_000_011F_01C7590A.38F47B80-- --===============1855965246== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1855965246==-- From nea-bounces@ietf.org Sun Feb 25 21:25:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVYp-0005xN-W5; Sun, 25 Feb 2007 21:25:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVYo-0005wH-Pt for nea@ietf.org; Sun, 25 Feb 2007 21:25:54 -0500 Received: from ccerelbas02.cce.hp.com ([161.114.21.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLVYj-0004zm-CF for nea@ietf.org; Sun, 25 Feb 2007 21:25:54 -0500 Received: from G3W0060.americas.hpqcorp.net (g3w0060.americas.hpqcorp.net [16.232.1.19]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 22DEF342C1 for ; Sun, 25 Feb 2007 20:25:49 -0600 (CST) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by G3W0060.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 02:25:49 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Feb 2007 02:25:46 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110113C554@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: REQ: section 6 comments Thread-Index: AcdZTWwbN5FEzEn9QOG++FfOr+9CqQ== From: "Sanchez, Mauricio (ProCurve)" To: X-OriginalArrivalTime: 26 Feb 2007 02:25:49.0325 (UTC) FILETIME=[6DD30BD0:01C7594D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [Nea] REQ: section 6 comments X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1748583070==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============1748583070== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0124_01C7590A.5DFE4B40"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_0124_01C7590A.5DFE4B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Section 6 comments/questions: 1. Section 6.1.1 - Consider decomposing the example scenario into more discrete use cases. In the current scenario you have initial connect-time assessment intermingled with the re-assessment use cases. Mixing together use cases makes defining clear requirement more difficult. 2. Section 6.1.1.2 - I don't believe step 14 is true. After the OS Patch validator signals success it's highly unlikely the user will physically re-connect to the network to get a re-assessment started. I suspect the NEA components have some facility to request global re-assessment, right? 3. Section 6.1.1.3 - Not sure what this section is trying to say. This section does highlight some characteristics of the example scenario, but I don't see how this translates into impact on requirements. Consider adding additional discussion to clarify. 4. Section 6.1.2 - What is meant by network service? Isn't the scenario described by section 6.1.1 essentially also an example of a request for a network service? Please compare/contrast somewhere initial network connect and request for network service. 5. Section 6.1.2.1 - This example triggered in my mind a new derivative use case. Namely, what about a use case that involves the need to pass multiple [concurrent] assessments? For example, what if I'm a guest at a company that provides guest LAN network connectivity as long as I pass muster via NEA. What if then I desire to connect back via VPN to my company's network that also requires passing security muster via NEA. This seems like a realistic and probable use case. Would NEA protocols support this? 6. Sections 6.1.2.3, 6.1.3.3, 6.2.1.3, 6.2.2.3 - same comment as for section 6.1.1.3. NITS A. Superfluous commas around "collectively" in first sentence of section 6.0 Cheers, MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- ------=_NextPart_000_0124_01C7590A.5DFE4B40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDIyNjAyMjU0NlowIwYJ KoZIhvcNAQkEMRYEFPDDdknlTR5dK9KtJ0czM6tZhCwkMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgJi1mYNI6Pt1pqsaL91V3WWVLRwbdbU9mXVihB+z+vhwIC5A8Vt+57sDllI/Cv8P pjksO9yVY0JimyFTwvaU6aWv9MQUQQQCJOj2m31mrRwRw5HcunzysjJxdD83Fpruqan9loWCX52+ esXNSwI1s6BDbXHKPmKQ5VwaxC7RyejlAAAAAAAA ------=_NextPart_000_0124_01C7590A.5DFE4B40-- --===============1748583070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1748583070==-- From nea-bounces@ietf.org Sun Feb 25 21:26:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVZa-0008Dv-Ja; Sun, 25 Feb 2007 21:26:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVZZ-0008Dk-MP for nea@ietf.org; Sun, 25 Feb 2007 21:26:41 -0500 Received: from ccerelbas02.cce.hp.com ([161.114.21.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLVZU-00055d-9Q for nea@ietf.org; Sun, 25 Feb 2007 21:26:41 -0500 Received: from G3W0060.americas.hpqcorp.net (g3w0060.americas.hpqcorp.net [16.232.1.19]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 0BC6E3439F for ; Sun, 25 Feb 2007 20:26:36 -0600 (CST) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by G3W0060.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 02:26:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Feb 2007 02:26:32 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110113C555@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: REQ: section 7 Thread-Index: AcdZTYeFmznTDRW6Smu3O5FfKzCQYw== From: "Sanchez, Mauricio (ProCurve)" To: X-OriginalArrivalTime: 26 Feb 2007 02:26:36.0216 (UTC) FILETIME=[89C60B80:01C7594D] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Subject: [Nea] REQ: section 7 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1277865610==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============1277865610== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0129_01C7590A.796BC740"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_0129_01C7590A.796BC740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My comments on section 7: 1. Section 7.1: In the NEA WG charter there's the statement, ".protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints." Which of the common requirements addresses what's detailed in the charter? 2. Section 7.1, requirement C-1 : Consider rephrasing this requirement for clarity. For example: "NEA protocols MUST be capable of supporting multi-round message exchanges between a NEA client and NEA server." 3. Section 7.1, requirement C-4: This requirement is too generic and besides the security threats outlined in the security section are not broken down into "active" and "passive" attacks, so establishment of what countermeasures satisfy this requirement is difficult. Consider being explicit in this requirement and stating exactly which active and passive attacks need to be thwarted. 4. Section 7.1, requirement C-6: Does the reference to "open standards" limit the candidate protocols to just those created by the IETF? I guess I'm asking for the definition of open standards. 5. Section 7.1, requirement C-8: How is "efficient" defined for NEA protocols? Is it about being frugal with the number of bits that need to be exchanged? Is it about being fast to be able to better cater to time-sensitive environments (e.g. A VoIP phone on a 802.11i network that has NEA enabled. You don't want a bloated protocol taking significant amount of time on each AP roam handoff). 6. Section 7.2, requirement PA-9: What are string attributes? It's the first time they're referenced. Are you really saying that the requirement for PA is that any human-readable attribute content (whether policy, compliance, posture, etc.) use a string encoding that supports internalization? Moreover, is this requirement not a common requirement for both PA and PB? 7. Section 7.4 : Why define requirements for PT if it's not within current NEA WG charter? Cheers, MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- ------=_NextPart_000_0129_01C7590A.796BC740 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDIyNjAyMjYzMlowIwYJ KoZIhvcNAQkEMRYEFMqKQY4LSQByuqYgTDsGETU2xtdaMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgIxU+KrF0WshNM0ocMxsonoXWBr3Mqo4C8SbYiDFQYgQKhYM5NBHIjes7543N/Gl Vg2n6z4u/LuG8NDCAgCx5oF3gSRAAxN0AELWv3dW8ocMMRB6uBxFMuZeo0Snq/wn7Bbput5elyXZ 6KnzfiIioakBxrb+tei4X6KlZUM/ODfnAAAAAAAA ------=_NextPart_000_0129_01C7590A.796BC740-- --===============1277865610== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1277865610==-- From nea-bounces@ietf.org Sun Feb 25 21:27:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVaE-0008Hf-6Z; Sun, 25 Feb 2007 21:27:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVaC-0008HU-TP for nea@ietf.org; Sun, 25 Feb 2007 21:27:20 -0500 Received: from ccerelbas02.cce.hp.com ([161.114.21.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLVa7-00059c-H3 for nea@ietf.org; Sun, 25 Feb 2007 21:27:20 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 386B034482 for ; Sun, 25 Feb 2007 20:27:15 -0600 (CST) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 20:27:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Feb 2007 02:27:12 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110113C556@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: REQ: section 8 Thread-Index: AcdZTZ9vKINEVuojQAC6aQZLQy8vJA== From: "Sanchez, Mauricio (ProCurve)" To: X-OriginalArrivalTime: 26 Feb 2007 02:27:15.0244 (UTC) FILETIME=[A1093EC0:01C7594D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Nea] REQ: section 8 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1483184355==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============1483184355== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_012E_01C7590A.91523F60"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_012E_01C7590A.91523F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My comments on section 8: 1. Section 8.1, ".NEA client frequently is expected to trust the network infrastructure not to misuse any disclosed Posture information." sentence: Doesn't the client always need to trust that the network infrastructure isn't going to misuse the posture information? What are some examples where it doesn't need to trust the infrastructure? 2. Section 8.1.3 - Isn't there a version of the "lying client" problem that is applicable to servers? What if my NEA server were compromised in a way that it no longer could be trusted to function correctly? I'd say each server component needs the same protection afforded to clients for the lying client problem. NITS 1. Missing comma after "However" in section 8.1.1, first paragraph, third sentence. 2. Extra comma after "NEA" in section 8.1.1, second paragraph, second sentence. Cheers, MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- ------=_NextPart_000_012E_01C7590A.91523F60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDIyNjAyMjcxMlowIwYJ KoZIhvcNAQkEMRYEFMBJMHqXiIq173wYgSIHfQFeLF8yMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgBxIJ+KWjpGGzh+aJCuUWpD8jTvUGRAblGeO4+nr3Eh9ryOW3l7klhD/j/mIOrn3 WP6+GzxuHdH9vu4cGaJoxEtPGpnZSvBI5zjFFZdjdK8hLiFebJoOWgshjqkTD4qtdZWC0y+4JPIk XwGvqXVURnfMLKVr+a2xIvq9/RC5F4pPAAAAAAAA ------=_NextPart_000_012E_01C7590A.91523F60-- --===============1483184355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1483184355==-- From nea-bounces@ietf.org Sun Feb 25 21:28:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVaz-0000Km-Lt; Sun, 25 Feb 2007 21:28:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVay-0000KP-VS for nea@ietf.org; Sun, 25 Feb 2007 21:28:08 -0500 Received: from ccerelbas02.cce.hp.com ([161.114.21.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLVat-0005Hp-Jd for nea@ietf.org; Sun, 25 Feb 2007 21:28:08 -0500 Received: from G3W0059.americas.hpqcorp.net (g3w0059.americas.hpqcorp.net [16.232.1.16]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 5AC3134493 for ; Sun, 25 Feb 2007 20:28:03 -0600 (CST) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by G3W0059.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 02:28:03 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Feb 2007 02:28:00 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110113C558@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: REQ: section 9 comments Thread-Index: AcdZTbwU2vXdRBIrRPm4lJOqV06SDg== From: "Sanchez, Mauricio (ProCurve)" To: X-OriginalArrivalTime: 26 Feb 2007 02:28:03.0360 (UTC) FILETIME=[BDB72A00:01C7594D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: [Nea] REQ: section 9 comments X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1164974021==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============1164974021== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0133_01C7590A.ADFA8550"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_0133_01C7590A.ADFA8550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Section 9 comments: 1. Section 9.2, second paragraph, "If deployer wishes to support Endpoint Assessment without a NEA client..." sentence. Two comments on this. First comment is that up until this point the document has never mentioned the possibility that NEA can be deployed without a client. Are clientless NEA deployments within scope of NEA WG? If so, then the reference model, use cases, and requirement section need elaboration with respects to clientless deployments. Second comment is that if NEA is going to make the claim that clientless deployments can improve privacy, there should be additional discussion as to how exactly privacy is improved. It's just too tantalizing of a claim to leave in a vague state. NITS a. Section 9.1, fourth paragraph, last sentence has an awkward structure. There's a "that a that which" that needs cleaning up. b. Section 9.2, fourth paragraph, second sentence. The word "Attribute" should be plural form ("Attributes"). c. Section 9.2, fifth paragraph, second sentence. Change "...to the policy being provision" to "...to the policy being provisioned". Cheers, MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- ------=_NextPart_000_0133_01C7590A.ADFA8550 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDIyNjAyMjgwMFowIwYJ KoZIhvcNAQkEMRYEFGyyWs3fReADbFBnFnLNXCrWbAPbMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgHwBId9hjwL6Y0RxEADkD+ZxolHe9IyvVrKhAE3/nzhc4S6jYW9pHiQRMZUVVx4n Ch6cPH/FrUFEp4c69gq1JQwhTK+2UDHF9nBZyLaAuhARj4cHXT6glKjwmQRoaDmttrHKYEbOwzcR m/3R2q9cQtY4rAsiPTVz1pVyNz05g39wAAAAAAAA ------=_NextPart_000_0133_01C7590A.ADFA8550-- --===============1164974021== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1164974021==-- From nea-bounces@ietf.org Sun Feb 25 21:28:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVbm-0000qA-LZ; Sun, 25 Feb 2007 21:28:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVbl-0000q4-VL for nea@ietf.org; Sun, 25 Feb 2007 21:28:57 -0500 Received: from ccerelbas02.cce.hp.com ([161.114.21.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLVbg-0005RW-K8 for nea@ietf.org; Sun, 25 Feb 2007 21:28:57 -0500 Received: from G3W0060.americas.hpqcorp.net (g3w0060.americas.hpqcorp.net [16.232.1.19]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 5EE17343D3 for ; Sun, 25 Feb 2007 20:28:52 -0600 (CST) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by G3W0060.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 02:28:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Feb 2007 02:28:50 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110113C55A@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: REQ: section 10 NITS Thread-Index: AcdZTdmCpmi11Bb1SRykF7yNFmj1Bg== From: "Sanchez, Mauricio (ProCurve)" To: X-OriginalArrivalTime: 26 Feb 2007 02:28:52.0560 (UTC) FILETIME=[DB0A7D00:01C7594D] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: [Nea] REQ: section 10 NITS X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1552443684==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============1552443684== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0138_01C7590A.CB64E2C0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_0138_01C7590A.CB64E2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Section 10 NITS 1. [CNAC] reference: Didn't you really mean ".Main Web Site." instead of ".Mail Web Site."? 2. [TNC] reference: Same as previous comment Cheers, MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- ------=_NextPart_000_0138_01C7590A.CB64E2C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDIyNjAyMjg1MFowIwYJ KoZIhvcNAQkEMRYEFK/M3U9ebwSKinVX61ZxYtfSrYM5MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgIcuiaCWqoTIGDaPOOvGeCIPqw1HszPj1H7h1IivF5lTsULo5OL4TL+e+3UkBhd4 FBdJjE3EEhb3GOagr5pE6Os4pY+tK3qW37z+SH4HnqzXlN8TGkLo7xVJawnjBtPY7GL1/hTvdt0d wpEQYYlicYbSO+KytI1pfOXExFASN2EsAAAAAAAA ------=_NextPart_000_0138_01C7590A.CB64E2C0-- --===============1552443684== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1552443684==-- From nea-bounces@ietf.org Mon Feb 26 22:11:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLsjN-0002bY-3i; Mon, 26 Feb 2007 22:10:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLsjM-0002b9-5n for nea@ietf.org; Mon, 26 Feb 2007 22:10:20 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLsjH-00028V-Ki for nea@ietf.org; Mon, 26 Feb 2007 22:10:20 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 31B5938C0E2; Mon, 26 Feb 2007 19:10:15 -0800 (PST) X-AuditID: d80ac287-9f59cbb000002978-1f-45e3a1170406 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 02697348004; Mon, 26 Feb 2007 19:10:15 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HLsjG-0002E1-T8; Mon, 26 Feb 2007 19:10:14 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 19:10:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: sections <= 2 Date: Mon, 26 Feb 2007 19:10:14 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DC0@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB2110113C552@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: sections <= 2 Thread-Index: AcdZTR2e0Qu1mxa1QhSnHu644vWgWwAyc7KQ References: <2F2D38A4B8346F48A683750A46BAB2110113C552@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 27 Feb 2007 03:10:14.0813 (UTC) FILETIME=[CCFDFCD0:01C75A1C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Comments below...=20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, February 25, 2007 6:24 PM > To: nea@ietf.org > Subject: [Nea] REQ: sections <=3D 2 >=20 > My comments/questions on sections less than or equal to two: >=20 > General NITs > 1.There seem to be some non-standard control characters=20 > present in the document. For example, in section 5.3 the=20 > usage of "nouns" in the second sentence shows up incorrectly. I see those in the browser as well but not in vi nor word ;). >=20 > 2.Some sections of the document refer to "vendor-defined"=20 > attributes while other refer to "vendor-specific" attributes.=20 > Isn't the term "vendor-specific" more widely used in other=20 > IETF efforts versus the "vendor-defined" term? If so, I=20 > suggest we change all references of "vendor-defined" to=20 > "vendor-specific." =20 Agreed this should be consistent. >=20 > 3.Why are "core" attributes not called "standard" attributes?=20 > After all, they're just the attributes that will be=20 > standarFrom nea-bounces@ietf.org Mon Feb 26 22:11:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLsjN-0002bY-3i; Mon, 26 Feb 2007 22:10:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLsjM-0002b9-5n for nea@ietf.org; Mon, 26 Feb 2007 22:10:20 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLsjH-00028V-Ki for nea@ietf.org; Mon, 26 Feb 2007 22:10:20 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 31B5938C0E2; Mon, 26 Feb 2007 19:10:15 -0800 (PST) X-AuditID: d80ac287-9f59cbb000002978-1f-45e3a1170406 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 02697348004; Mon, 26 Feb 2007 19:10:15 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HLsjG-0002E1-T8; Mon, 26 Feb 2007 19:10:14 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 19:10:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: sections <= 2 Date: Mon, 26 Feb 2007 19:10:14 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DC0@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB2110113C552@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: sections <= 2 Thread-Index: AcdZTR2e0Qu1mxa1QhSnHu644vWgWwAyc7KQ References: <2F2D38A4B8346F48A683750A46BAB2110113C552@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 27 Feb 2007 03:10:14.0813 (UTC) FILETIME=[CCFDFCD0:01C75A1C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Comments below...=20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, February 25, 2007 6:24 PM > To: nea@ietf.org > Subject: [Nea] REQ: sections <=3D 2 >=20 > My comments/questions on sections less than or equal to two: >=20 > General NITs > 1.There seem to be some non-standard control characters=20 > present in the document. For example, in section 5.3 the=20 > usage of "nouns" in the second sentence shows up incorrectly. I see those in the browser as well but not in vi nor word ;). >=20 > 2.Some sections of the document refer to "vendor-defined"=20 > attributes while other refer to "vendor-specific" attributes.=20 > Isn't the term "vendor-specific" more widely used in other=20 > IETF efforts versus the "vendor-defined" term? If so, I=20 > suggest we change all references of "vendor-defined" to=20 > "vendor-specific." =20 Agreed this should be consistent. >=20 > 3.Why are "core" attributes not called "standard" attributes?=20 > After all, they're just the attributes that will be=20 > standardized by NEA WG. To me calling them "standard"=20 > attributes is a more intuitive label than "core." Agreed (and this matches the named used in the charter.) >=20 > 4.Have IETF writing styles changed such that all terms=20 > defined in the terminology section need to be capitalized? =20 > If so, then there are instances where this guideline are not=20 > followed (e.g. the term 'reference model' is not capitalized=20 > in abstract section vs. rest of document). IMHO, extreme=20 > usage of capitalized terms, as is the case with this=20 > document, detracts from the readability. We wanted to call out when we were using a defined term vs. the generic equivalent (roughly equivalent of SHOULD vs should.) Since we use a few commonly used words (e.g. Message, Component ...) with a special meaning we thought it was important to be clear what was intended. For sections that are prior to the terminology section we didn't wish to use defined terms (since they weren't defined yet) and instead stick with generally known wordings. Another WG member already pointed out that we missed a few terms that were used in the abstract (which is fixed in -01.) If others agree that this hurts readibility we could make them lower case as well and hope the reader understands this is a reserved term for this spec. >=20 > Section 2 specific comments > 1. How exactly do policy attributes differ from posture=20 > attributes? It's unclear to me because of the claim in the Policy Attributes describe or reference policies that the Endpoint must meet to be considered compliant ("must have firewall running at least version 1.2.3"). These are sent by the NEA Server (will add text to mention this.) Posture Attributes includes Posture information about a requested Component (Firewall installed, version 1.5, Firewall running, ...) The Posture Validator compares this information to its policy to determine compliance. These are sent by the NEA Client. > definition of policy attributes that states that policy=20 > attributes can be used to establish compliancy without=20 > divulging posture information. Isn't the exchange of policy=20 > and compliance attributes in fact a form of posture=20 > information exchange.=20 I presume you mean Policy and Compliance Claim Attributes. In some sense you could argue this but we felt it was important to be more clear about the different types of attributes as they have differing security, privacy and operational properties. We found these names very helpful when writing the spec and hope that after a read of the draft they aren't confusing. =20 >=20 > Cheers, > MS >=20 > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > ProCurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5557 > Roseville CA, 95747-5557 >=20 > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- =20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Feb 26 22:11:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLsjy-0003kg-UT; Mon, 26 Feb 2007 22:10:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLsjx-0003kR-1M for nea@ietf.org; Mon, 26 Feb 2007 22:10:57 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLsjv-0002Cj-Oz for nea@ietf.org; Mon, 26 Feb 2007 22:10:57 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 60EBD38C0F2; Mon, 26 Feb 2007 19:10:55 -0800 (PST) X-AuditID: d80ac287-9eb9bbb000002978-4b-45e3a13fcb98 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) dized by NEA WG. To me calling them "standard"=20 > attributes is a more intuitive label than "core." Agreed (and this matches the named used in the charter.) >=20 > 4.Have IETF writing styles changed such that all terms=20 > defined in the terminology section need to be capitalized? =20 > If so, then there are instances where this guideline are not=20 > followed (e.g. the term 'reference model' is not capitalized=20 > in abstract section vs. rest of document). IMHO, extreme=20 > usage of capitalized terms, as is the case with this=20 > document, detracts from the readability. We wanted to call out when we were using a defined term vs. the generic equivalent (roughly equivalent of SHOULD vs should.) Since we use a few commonly used words (e.g. Message, Component ...) with a special meaning we thought it was important to be clear what was intended. For sections that are prior to the terminology section we didn't wish to use defined terms (since they weren't defined yet) and instead stick with generally known wordings. Another WG member already pointed out that we missed a few terms that were used in the abstract (which is fixed in -01.) If others agree that this hurts readibility we could make them lower case as well and hope the reader understands this is a reserved term for this spec. >=20 > Section 2 specific comments > 1. How exactly do policy attributes differ from posture=20 > attributes? It's unclear to me because of the claim in the Policy Attributes describe or reference policies that the Endpoint must meet to be considered compliant ("must have firewall running at least version 1.2.3"). These are sent by the NEA Server (will add text to mention this.) Posture Attributes includes Posture information about a requested Component (Firewall installed, version 1.5, Firewall running, ...) The Posture Validator compares this information to its policy to determine compliance. These are sent by the NEA Client. > definition of policy attributes that states that policy=20 > attributes can be used to establish compliancy without=20 > divulging posture information. Isn't the exchange of policy=20 > and compliance attributes in fact a form of posture=20 > information exchange.=20 I presume you mean Policy and Compliance Claim Attributes. In some sense you could argue this but we felt it was important to be more clear about the different types of attributes as they have differing security, privacy and operational properties. We found these names very helpful when writing the spec and hope that after a read of the draft they aren't confusing. =20 >=20 > Cheers, > MS >=20 > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > ProCurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5557 > Roseville CA, 95747-5557 >=20 > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- =20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Feb 26 22:11:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLsjy-0003kg-UT; Mon, 26 Feb 2007 22:10:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLsjx-0003kR-1M for nea@ietf.org; Mon, 26 Feb 2007 22:10:57 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLsjv-0002Cj-Oz for nea@ietf.org; Mon, 26 Feb 2007 22:10:57 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 60EBD38C0F2; Mon, 26 Feb 2007 19:10:55 -0800 (PST) X-AuditID: d80ac287-9eb9bbb000002978-4b-45e3a13fcb98 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 219CA348002; Mon, 26 Feb 2007 19:10:55 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HLsjv-0000yB-11; Mon, 26 Feb 2007 19:10:55 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 19:10:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: section 10 NITS Date: Mon, 26 Feb 2007 19:10:45 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DC1@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB2110113C55A@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: section 10 NITS Thread-Index: AcdZTdmCpmi11Bb1SRykF7yNFmj1BgAzu0ww References: <2F2D38A4B8346F48A683750A46BAB2110113C55A@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 27 Feb 2007 03:10:54.0860 (UTC) FILETIME=[E4DCACC0:01C75A1C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Thanks we caught those :).=20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, February 25, 2007 6:29 PM > To: nea@ietf.org > Subject: [Nea] REQ: section 10 NITS >=20 > Section 10 NITS > 1. [CNAC] reference: Didn't you really mean ".Main Web=20 > Site." instead of ".Mail Web Site."? > 2. [TNC] reference: Same as previous comment >=20 > Cheers, > MS >=20 > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > ProCurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5557 > Roseville CA, 95747-5557 >=20 > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- =20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 219CA348002; Mon, 26 Feb 2007 19:10:55 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HLsjv-0000yB-11; Mon, 26 Feb 2007 19:10:55 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 19:10:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: section 10 NITS Date: Mon, 26 Feb 2007 19:10:45 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DC1@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB2110113C55A@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: section 10 NITS Thread-Index: AcdZTdmCpmi11Bb1SRykF7yNFmj1BgAzu0ww References: <2F2D38A4B8346F48A683750A46BAB2110113C55A@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 27 Feb 2007 03:10:54.0860 (UTC) FILETIME=[E4DCACC0:01C75A1C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Thanks we caught those :).=20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, February 25, 2007 6:29 PM > To: nea@ietf.org > Subject: [Nea] REQ: section 10 NITS >=20 > Section 10 NITS > 1. [CNAC] reference: Didn't you really mean ".Main Web=20 > Site." instead of ".Mail Web Site."? > 2. [TNC] reference: Same as previous comment >=20 > Cheers, > MS >=20 > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > ProCurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5557 > Roseville CA, 95747-5557 >=20 > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- =20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Feb 26 22:54:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtQ2-0003SV-A7; Mon, 26 Feb 2007 22:54:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtQ1-0003Iv-8T for nea@ietf.org; Mon, 26 Feb 2007 22:54:25 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLtPz-00072L-P3 for nea@ietf.org; Mon, 26 Feb 2007 22:54:25 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 52E5138C2CE; Mon, 26 Feb 2007 19:54:23 -0800 (PST) X-AuditID: d80ac287-9e19abb000002978-9b-45e3ab6faf5d Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 239DB348003; Mon, 26 Feb 2007 19:54:23 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HLtPz-0002xn-19; Mon, 26 Feb 2007 19:54:23 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 19:53:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: section 6 comments Date: Mon, 26 Feb 2007 19:53:07 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DDD@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB2110113C554@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: section 6 comments Thread-Index: AcdZTWwbN5FEzEn9QOG++FfOr+9CqQAz4axA References: <2F2D38A4B8346F48A683750A46BAB2110113C554@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 27 Feb 2007 03:53:12.0781 (UTC) FILETIME=[CD94AFD0:01C75A22] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org =20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, February 25, 2007 6:26 PM > To: nea@ietf.org > Subject: [Nea] REQ: section 6 comments >=20 > Section 6 comments/questions: > 1. Section 6.1.1 - Consider decomposing the example=20 > scenario into more > discrete use cases. In the current scenario you have initial=20 > connect-time assessment intermingled with the re-assessment=20 > use cases. Mixing together use cases makes defining clear=20 > requirement more difficult.=20 One of the goals of the spec was to broadly describe the problem space in the use case (examples.) We carefully allocated different aspects of the problem space to each of the 5 use case areas. We recognized that the 1st use case was pretty complex (but is likely a well understood scenario) so you'll note step 14 doesn't go into the re-assessment details. If we separated out the remediation it wouldn't make this much simpler (removes steps 14-16 only.) >=20 > 2. Section 6.1.1.2 - I don't believe step 14 is true. =20 > After the OS > Patch validator signals success it's highly unlikely the user=20 > will physically re-connect to the network to get a=20 > re-assessment started. I suspect the NEA components have=20 > some facility to request global re-assessment, right? Correct, we'll try to fix the wording. Note however that step 1 doesn't mention booting or user interaction just that: "The IT employee's desktop computer connects to the network...". If it helps we could address this comment. >=20 > 3. Section 6.1.1.3 - Not sure what this section is trying=20 > to say. This > section does highlight some characteristics of the example=20 > scenario, but I don't see how this translates into impact on=20 > requirements. Consider adding additional discussion to clarify. Ok. These are "different aspects of the problem space" mentioned above that could impact the requirement definitions. Some text to explain this would be helpful. >=20 > 4. Section 6.1.2 - What is meant by network service? Isn't the > scenario described by section 6.1.1 essentially also an=20 > example of a request for a network service? Please=20 > compare/contrast somewhere initial network connect and=20 > request for network service. I presume the example given in 6.1.2 wasn't sufficent (detailed enough)? One could imagine this being a request to a protected service like the Financial Portal server which contains very sensitive and mission critical data. We used the example of VPN to show an L3 (instead of L7) service request but as you mention this smells similar to the L2 initial network connect example. We could switch it if others feel this is important. >=20 >=20 > 5. Section 6.1.2.1 - This example triggered in my mind a=20 > new derivative > use case. Namely, what about a use case that involves the=20 > need to pass multiple [concurrent] assessments? For example,=20 > what if I'm a guest at a company that provides guest LAN=20 > network connectivity as long as I pass muster via NEA. What=20 > if then I desire to connect back via VPN to my company's=20 > network that also requires passing security muster via NEA. =20 > This seems like a realistic and probable use case. Would NEA=20 > protocols support this? Certainly more complicated and I'm not sure this introduces an aspect of the problem space that we didn't already cover. I presume this would just be 2 independent assessments without knowledge of each other (?). >=20 > 6. Sections 6.1.2.3, 6.1.3.3, 6.2.1.3, 6.2.2.3 - same=20 > comment as for > section 6.1.1.3. Yes >=20 > NITS >=20 > A. Superfluous commas around "collectively" in first sentence of > section 6.0 Thanks >=20 > Cheers, > MS >=20 > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > ProCurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5557 > Roseville CA, 95747-5557 >=20 > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- =20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Feb 26 22:55:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtQx-0004g1-8g; Mon, 26 Feb 2007 22:55:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtQw-0004fs-Rh for nea@ietf.org; Mon, 26 Feb 2007 22:55:22 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLtQv-0007A1-Ed for nea@ietf.org; Mon, 26 Feb 2007 22:55:22 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 1BD2F38C2E2; Mon, 26 Feb 2007 19:55:21 -0800 (PST) X-AuditID: d80ac287-a2231bb000002978-57-45e3aba812df Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id F2EC1348004; Mon, 26 Feb 2007 19:55:20 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HLtQu-0004D8-Rr; Mon, 26 Feb 2007 19:55:20 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 19:55:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: section 7 Date: Mon, 26 Feb 2007 19:55:15 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DE0@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB2110113C555@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: section 7 Thread-Index: AcdZTYeFmznTDRW6Smu3O5FfKzCQYwA1W9Tg References: <2F2D38A4B8346F48A683750A46BAB2110113C555@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 27 Feb 2007 03:55:20.0749 (UTC) FILETIME=[19DB0DD0:01C75A23] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org We'll get back to you on these comments. At the moment we were looking to discuss all the other sections first (agree on context for the requirements.) Thanks for your completeness!=20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, February 25, 2007 6:27 PM > To: nea@ietf.org > Subject: [Nea] REQ: section 7 >=20 > My comments on section 7: > 1. Section 7.1: In the NEA WG charter there's the statement, > ".protocols developed by the NEA WG must be designed to=20 > accommodate emerging technologies for identifying and dealing=20 > with lying endpoints." Which of the common requirements=20 > addresses what's detailed in the charter? > 2. Section 7.1, requirement C-1 : Consider rephrasing=20 > this requirement > for clarity. For example: "NEA protocols MUST be capable of=20 > supporting multi-round message exchanges between a NEA client=20 > and NEA server." > 3. Section 7.1, requirement C-4: This requirement is too=20 > generic and > besides the security threats outlined in the security section=20 > are not broken down into "active" and "passive" attacks, so=20 > establishment of what countermeasures satisfy this=20 > requirement is difficult. Consider being explicit in this=20 > requirement and stating exactly which active and passive=20 > attacks need to be thwarted. =20 > 4. Section 7.1, requirement C-6: Does the reference to=20 > "open standards" > limit the candidate protocols to just those created by the=20 > IETF? I guess I'm asking for the definition of open standards. > 5. Section 7.1, requirement C-8: How is "efficient" defined for NEA > protocols? Is it about being frugal with the number of bits=20 > that need to be exchanged? Is it about being fast to be able=20 > to better cater to time-sensitive environments (e.g. A VoIP=20 > phone on a 802.11i network that has NEA enabled. You don't=20 > want a bloated protocol taking significant amount of time on=20 > each AP roam handoff).=20 > 6. Section 7.2, requirement PA-9: What are string=20 > attributes? It's > the first time they're referenced. Are you really saying=20 > that the requirement for PA is that any human-readable=20 > attribute content (whether policy, compliance, posture, etc.)=20 > use a string encoding that supports internalization? =20 > Moreover, is this requirement not a common requirement for=20 > both PA and PB? > 7. Section 7.4 : Why define requirements for PT if it's not within > current NEA WG charter? >=20 > Cheers, > MS >=20 >=20 > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > ProCurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5557 > Roseville CA, 95747-5557 >=20 > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- =20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Feb 26 23:08:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtd1-0004rN-1l; Mon, 26 Feb 2007 23:07:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtd0-0004ka-3W for nea@ietf.org; Mon, 26 Feb 2007 23:07:50 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLtcy-0008Tg-Mz for nea@ietf.org; Mon, 26 Feb 2007 23:07:50 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 5668438C07C; Mon, 26 Feb 2007 20:07:48 -0800 (PST) X-AuditID: d80ac287-9f59cbb000002978-8e-45e3ae946a7d Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 23036348002; Mon, 26 Feb 2007 20:07:48 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HLtcy-0003eF-0N; Mon, 26 Feb 2007 20:07:48 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 20:07:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: section 8 Date: Mon, 26 Feb 2007 20:07:40 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DE5@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB2110113C556@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: section 8 Thread-Index: AcdZTZ9vKINEVuojQAC6aQZLQy8vJAA1bpLA References: <2F2D38A4B8346F48A683750A46BAB2110113C556@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 27 Feb 2007 04:07:47.0885 (UTC) FILETIME=[D72EF5D0:01C75A24] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org =20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, February 25, 2007 6:27 PM > To: nea@ietf.org > Subject: [Nea] REQ: section 8 >=20 > My comments on section 8: > 1. Section 8.1, ".NEA client frequently is expected to trust=20 > the network infrastructure not to misuse any disclosed=20 > Posture information." sentence: > Doesn't the client always need to trust that the network=20 > infrastructure isn't going to misuse the posture information?=20 > What are some examples where it doesn't need to trust the=20 > infrastructure? We could make this absolute but their could be situations where the client didn't disclose any sensitive information that it cares about being disclosed to other parties (e.g. when it sends only Compliance Claim Attributes.) Another option might be that the employment agreement the Endpoint User signed states that the Endpoint Owner (who is also the network Owner) can make use of the information in any way it sees fit. In general, I agree with your comment but wanted to leave the door open for (hopefully!) less common situations. Maybe we should change "frequently" to "normally"? > 2. Section 8.1.3 - Isn't there a version of the "lying=20 > client" problem that is applicable to servers? What if my=20 > NEA server were compromised in a way that it no longer could=20 > be trusted to function correctly? I'd say each server=20 > component needs the same protection afforded to clients for=20 > the lying client problem. Can you explain more? In these examples the server isn't being assessed by the client. If it were being assessed, then this would be an issue. What did you have in mind (is it the server being assessed)? In this case the NEA Server would run on the Endpoint and the NEA Client on the "server". >=20 > NITS > 1. Missing comma after "However" in section 8.1.1, first=20 > paragraph, third sentence. > 2. Extra comma after "NEA" in section 8.1.1, second=20 > paragraph, second sentence. Ah that's where the comma went :). >=20 > Cheers, > MS >=20 > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > ProCurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5557 > Roseville CA, 95747-5557 >=20 > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- =20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Feb 26 23:21:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtqM-0008KI-JQ; Mon, 26 Feb 2007 23:21:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtqK-0008Jk-PC for nea@ietf.org; Mon, 26 Feb 2007 23:21:36 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLtqC-0001fH-7s for nea@ietf.org; Mon, 26 Feb 2007 23:21:36 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id D83AC38C1ED; Mon, 26 Feb 2007 20:21:27 -0800 (PST) X-AuditID: d80ac287-9eb9bbb000002978-a0-45e3b1c7231c Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id B67CA348005; Mon, 26 Feb 2007 20:21:27 -0800 (PST) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HLtqB-0005OK-Kj; Mon, 26 Feb 2007 20:21:27 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Feb 2007 20:21:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Clientless NEA Endpoints? (Was RE: [Nea] REQ: section 9 comments) Date: Mon, 26 Feb 2007 20:21:11 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DEF@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB2110113C558@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clientless NEA Endpoints? (Was RE: [Nea] REQ: section 9 comments) Thread-Index: AcdZTbwU2vXdRBIrRPm4lJOqV06SDgA1ztjw References: <2F2D38A4B8346F48A683750A46BAB2110113C558@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 27 Feb 2007 04:21:16.0161 (UTC) FILETIME=[B8F41710:01C75A26] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Changing subjects in hopes of a thread emerging...=20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, February 25, 2007 6:28 PM > To: nea@ietf.org > Subject: [Nea] REQ: section 9 comments >=20 > Section 9 comments: >=20 > 1. Section 9.2, second paragraph, "If deployer wishes to=20 > support Endpoint Assessment without a NEA client..."=20 > sentence. Two comments on this. =20 >=20 > First comment is that up until this point the document has=20 > never mentioned the possibility that NEA can be deployed=20 > without a client. Are clientless NEA deployments within=20 > scope of NEA WG? If so, then the reference model, use cases,=20 > and requirement section need elaboration with respects to=20 > clientless deployments.=20 Thanks for asking this. We had planned to raise this at the WG meeting and on the alias soon. What do folks think about this? The design team discussed it at length and decided we should ask the WG. The downside of including clientless is that the NEA Client components wouldn't be running on the Endpoint which is confusing and would require us to do a lot of rewording (likely remaining confusing.) The upside is this has better privacy properties and reflects real world situations where no NEA Client is running on the Endpoint. However some of these common cases may not be in scope for NEA (visitor who Owns her laptop and does not wish to consent to an invasive assessment when joining a network ...) =20 >=20 > Second comment is that if NEA is going to make the claim that=20 > clientless deployments can improve privacy, there should be=20 > additional discussion as to how exactly privacy is improved. =20 > It's just too tantalizing of a claim to leave in a vague state. Ok. Based on what the WG thinks we should do here we'll address your comments (likely in -03.) =20 >=20 >=20 > NITS > a. Section 9.1, fourth paragraph, last sentence has an=20 > awkward structure. > There's a "that a that which" that needs cleaning up.=20 > b. Section 9.2, fourth paragraph, second sentence. The word=20 > "Attribute" > should be plural form ("Attributes"). > c. Section 9.2, fifth paragraph, second sentence. Change=20 > "...to the policy being provision" to "...to the policy being=20 > provisioned". Thanks >=20 > Cheers, > MS >=20 > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > ProCurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5557 > Roseville CA, 95747-5557 >=20 > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- =20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Feb 27 02:27:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLwjy-0004Fh-HV; Tue, 27 Feb 2007 02:27:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLwjw-0004DQ-SD for nea@ietf.org; Tue, 27 Feb 2007 02:27:13 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLwjs-0003PU-8W for nea@ietf.org; Tue, 27 Feb 2007 02:27:12 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 54EE438C1F1; Mon, 26 Feb 2007 23:27:01 -0800 (PST) X-AuditID: d80ac287-9f59cbb000002978-85-45e3dd45902b Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 03738348003; Mon, 26 Feb 2007 23:27:01 -0800 (PST) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HLwjk-0003Yf-TI; Mon, 26 Feb 2007 23:27:00 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Feb 2007 23:27:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: Section 5 comments Date: Mon, 26 Feb 2007 23:26:58 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A025A8E2E@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB2110113C553@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 5 comments Thread-Index: AcdZTUcDOBr2jfMtQ6a6RDSRtgZTNAA58Fdg References: <2F2D38A4B8346F48A683750A46BAB2110113C553@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 27 Feb 2007 07:27:00.0414 (UTC) FILETIME=[AB7225E0:01C75A40] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Many thanks for the thorough review! The Design Team will be working to incorporate as many of your comments as we can into -01 this week (assuming other WG members don't object soon.) > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, February 25, 2007 6:25 PM > To: nea@ietf.org > Subject: [Nea] REQ: Section 5 comments >=20 > Several comments/questions about section 5 [Reference Model]: >=20 > 1. Meta-comment: The model seems to assume that an=20 > endpoint consists of > only one processing entity (OS, hardware, etc.). It's=20 > unclear how the model and the adjunct requirements may need=20 > to get modified in light of rising popularity in system=20 > virtualization. For example, it likely that multiple posture=20 > broker clients and posture transport clients will exist on=20 > single hardware system that's been virtualized into multiple=20 > systems. I'd say additional thought is necessary in this area=20 > or we just punt and explicitly say that it's out of scope at=20 > this time. Which virtualization model are you concerned about? Is it hypervisor style (multi guest OSes and/or virtual appliances) as per a Xen model? If so, why couldn't the NEA Client just run in each guest OS and provide Posture like it would in a non-virtualized environment? If multiple guest OSes exist, each normally have their own network interfaces (possibly [para]virtualized) but they could report their Posture when requested on their interface (or when attempting to connect to the network.) The primary difference I see is the potential lack of Posture about the hypervisor layer but this could be addressed in different ways. This might be an interesting dialog to have on the alias to determine if we need to push this out of scope or whether this is similar enough to our model that it could remain in scope and be discussed. >=20 > 2. Meta-comment: Section 9 describes several suggestions on how to > introduce user facilities to manage privacy. In that section=20 > there's no specific guidance on which components should=20 > implement the suggested privacy enhancements. If not in=20 > section 9, wouldn't it be useful to assign the privacy=20 > enhancements to the model/components described in section 5? =20 > For example, I could envision seeing the posture collectors=20 > and posture broker client sharing responsibilities in proving=20 > a user the necessary UI and privacy policy management=20 > capabilities described in section 9. =20 This might be a good addition to section 9 to make it more specific. >=20 > 3. Meta-comment: The model describes the existence of protocols > between like layers (e.g. posture collector <--PA--> posture=20 > validator, posture broker client <--PB--> posture broker=20 > server), but provides no description as to what happens=20 > between different layers (posture collector <-> posture=20 > broker). I suspect that there's an unwritten assumption that=20 > different layers may communicate using APIs. If so, I=20 > suggest that at a minimum there be some suggestion on how=20 > different layers may be communicating (e.g. APIs) and noting=20 > that such work is out of scope for the current WG charter=20 > (and IETF in general).=20 These were discussed during the formation of NEA and are out of scope. We could add a sentence to state this in section 5 (or 3.1.) I'd rather not make a statement whether they are API or protocol interfaces. >=20 > Side note: Section 5.1.2.2 states that validators may be=20 > physically remote to the server. Doesn't this particular=20 > situation give rise to yet another > protocol for the NEA model to denote? I can imagine the=20 > existence of a PV > (Posture Validator) protocol between a remote posture=20 > validator and a posture broker server. Even though the=20 > current WG charter precludes working on any protocol other=20 > than PA and PB, we should nonetheless strive for completeness=20 > in the description of the model.=20 This was discussed as well during the BOFs but was also removed from the final reference model presented by the chairs during the San Diego NEA WG meeting and the model used prior to our approval to become a WG. The current model only names the protocols we intend to specify requirements for in this spec. With that said we did want to mention that the Posture Validators could be remote in the text (as you noted) because this might impact the security model and it helps understand why a deployer might wish to use strong security protections on the PA Messages. Did you have a specific change in mind? Is it something we can mention without defining and showing PV as a formal protocol (e.g. extend some of the text in 5.1.2.[1,2]?) >=20 > 4. Meta-comment: The document introduction (section 1.0)=20 > describes the > existence of an enforcement entity to enforce the final=20 > admission decision. > Although I understand that mechanisms and protocols for=20 > enforcement are out of scope, shouldn't the NEA model diagram=20 > and description at least acknowledge that an enforcement=20 > entity exists? There should be a general goal of having a=20 > comprehensive ENA model, even if complete treatment of all=20 > components and protocols are not currently within NEA charter.=20 We had this discussion at the NEA WG meeting in San Diego when the enforcement device was removed from the diagram (pre I-D). Their has been a desire by folks in the WG to stay independent of the network access layer. >=20 > 5. Section 5.0: Discussion of reference model includes=20 > statement: "This > model is provided to establish a context for the discussion=20 > of requirements and may not directly map to any particular=20 > product or deployment architecture." This statement seems to=20 > contradict the statement made in the abstract that the NEA=20 > reference model is based on the models used by CNAC, NAP and TNC. It merely represents the intended use of the model (component and protocol naming) for the purposes of this document. The CNAC, NAP and TNC have similar analogous models which was the point of the abstract. >=20 > 6. Section 5.1.1.1, last paragraph: From an interoperability > perspective NEA should evaluate mandating a minimum amount of=20 > functionality > so as to improve the odds of interoperable implementations. Or at a > minimum there should be some form of signaling introduced=20 > into the protocol to provide for component capability advertisement. Is your point that the Posture Collector could support a fairly wide variety of classes of Attributes and likely a variety of specific Attributes so its difficult for a Posture Validator to know which ones are supported? When we define the PA protocol, we should be able to address this issue. Is their a requirement you'd like to see added for PA to enable this capability discovery or just add text to 5.1.1.1 to describe the situation? =20 >=20 > 7. Section 5.1.1.2, first paragraph, second sentence:=20 > "...forwarding > the request to the appropriate Posture Collectors." This=20 > sentence sounds like a request always goes to multiple=20 > collectors. I don't believe this is always the case, or is it?=20 No its based upon which Posture Collectors are involved (requested to be) in the assessment. Will clean-up the text to help. =20 >=20 > 8. Section 5.1.1.2, first paragraph, third sentence: "The Posture > Broker Client also multiplexes the responses from the Posture=20 > Collector..." > This sentence doesn't acknowledge that there may be one or=20 > more posture collectors. Consider changing to=20 > "...multiplexes the responses from Posture Collector(s)..." Ok >=20 > 9. Section 5.1.1.3 mentions that there may be more than one posture > transport client on an endpoint. I suggest updating the=20 > diagram of the model detailing this fact (e.g. add "(1...n)"=20 > to posture transport client block as was done for posture=20 > collector). Furthermore, it'd be useful to describe why=20 > multiple transport clients may be necessary. =20 Ok >=20 > 10. Section 5.1.2.1 mentions that a posture validator may=20 > be located on > a separate server from the posture server. It goes on to say=20 > that the server may have to with both local and remote=20 > validators. One can assume that in the instance=20 I can't parse this ... >=20 > 11. Section 5.1.2.2 describes as one of the roles being,=20 > "Communicating > with remote Posture Validators and providing cryptographic=20 > protection for > this communication." It's unclear to me what this exactly=20 > means. The > broker server doesn't have any direct relationships with a=20 > posture validator, or does it? Furthermore, it's not clear The Posture Broker Server communicates (API or protocol) with the Posture Validator(s) to pass PA Messages (and decisions.) =20 > at what level the cryptographic protection is being provided.=20 > In section 5.1.1.3 (about posture transport client) it state=20 > clearly that its role is to protect the message dialog. I=20 > suggest the same level of clarity for server broker's role. Maybe this should be removed since this protocol is out of scope if its confusing. We expected that their might be a security protocol between the Posture Broker Server and Posture Validator. Within NEA scope, the PA Messages could be encrypted/integrity protected end-to-end and flow over this link but the Posture Broker Server doesn't have to do anything special for this to occur. >=20 > 12. Section 5.1.2.2 - Is it not the role of the posture=20 > broker server to > also establish the overall compliance decision for an=20 > endpoint? Currently the document only assigns the generation=20 > of the global posture decision. If not the broker server,=20 > which component generates the overall compliance decision? =20 > Or is the global posture decision in fact the compliance=20 > decision? I'm confused. Global posture decision =3D=3D overall compliance decision We don't use the expression "overall compliance decision" >=20 > 13. Section 5.1.2.3 - Why may there be more than one=20 > posture transport > server in a particular NEA server? If there are truly=20 > multiple posture transport servers, then the NEA model=20 > diagram should be updated to reflect this possibility. See comment #8. One for each transport/carrier protocol. You might imagine one for IPsec, one for 802.1x, one for SSL, ... We will consider revising the diagram. >=20 > 14. Section 5.1.2.3 - The statement "Providing=20 > cryptographic protection > for Posture information." is not as clear as the one used for=20 > the posture transport client. For the posture transport=20 > client the described role is protection of message dialog. =20 > It's probably the same for the transport server and should be=20 > designated as such in the document.=20 Agreed >=20 > 15. Section 5.3.1 - I sense there is at some level some relationship > between the attributes sent by a NEA server (i.e. requests)=20 > and those sent by a NEA client (i.e. responses). For=20 > example, isn't it the case that request attributes always and=20 > only elicit posture attributes as a response? > Likewise, couldn't the same be said of policy attributes and=20 > compliance claim attributes? If so, it may be useful to=20 > highlight these relationships to make the protocol easier to=20 > understand.=20 We'll work to make the relationships more clear. We did this already for Compliance Claim and Policy Attributes but not Request and Posture Attributes. >=20 > 16. Section 5.3.2 - It's unclear to me to what level the remediation > attributes will get defined. On one hand the intro to this=20 > section (5.3) states that NEA WG will define a standard set=20 > of attributes. By the same token other parts of the document=20 > (e.g. section 3.1 - scope) state the > standard protocols for remediation are out of scope. In defining > remediation attributes are we not inadvertently defining a=20 > standard protocol for remediation?=20 We decided to define the class of attributes so they can be a distinct class (possibly becoming a separate name space) but we don't expect NEA will define the specific attribute names/values due to our charter limitation. It was handy to define the term for these attributes so we could reference where they fit in the model/examples but that is all we expected would be done with them. >=20 >=20 > NITS > a. Misplaced period in last sentence of section 5. [Reference=20 > model]. Period goes outside parenthesis bracket.=20 > b. Misplaced commas and periods in first sentence of 5.1.1.1=20 > c. Misplaced period in last sentence of second paragraph of=20 > section 5.1.1.1. > Same disposition as NIT 3a. Thanks > d. Missing period on second bullet of section 5.1.1.2 e. Why=20 > is Message Dialog capitalized? See comment 7a. Both are reserved words for this I-D (this is why the capitalization is handy.) Without it (unless your very familiar with the document) its hard to know what words have a particular defined meaning in the draft. > f. Change "Posture Transport Clients" to "Posture Transport=20 > Client" in section 5.1.1.3, first paragraph, last sentence. Thanks >=20 > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > ProCurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5557 > Roseville CA, 95747-5557 >=20 > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- =20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Feb 27 04:46:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLyuP-0005Qe-En; Tue, 27 Feb 2007 04:46:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLyuN-0005QT-KG for nea@ietf.org; Tue, 27 Feb 2007 04:46:07 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLyuL-0001MQ-SA for nea@ietf.org; Tue, 27 Feb 2007 04:46:07 -0500 Received: from [10.0.1.60] (alexander.quiconnect.net [213.30.156.62]) by book.deployingradius.com (Postfix) with ESMTP id 7D638A70B4; Tue, 27 Feb 2007 01:45:53 -0800 (PST) Message-ID: <45E3FDD0.8080906@deployingradius.com> Date: Tue, 27 Feb 2007 10:45:52 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Paul Sangster Subject: Re: Clientless NEA Endpoints? (Was RE: [Nea] REQ: section 9 comments) References: <2F2D38A4B8346F48A683750A46BAB2110113C558@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8DEF@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DEF@SVL1XCHCLUPIN02.enterprise.veritas.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Paul Sangster wrote: >> First comment is that up until this point the document has >> never mentioned the possibility that NEA can be deployed >> without a client. Are clientless NEA deployments within >> scope of NEA WG? If so, then the reference model, use cases, >> and requirement section need elaboration with respects to >> clientless deployments. > > Thanks for asking this. We had planned to raise this at the WG meeting > and on the alias soon. What do folks think about this? The design team > discussed it at length and decided we should ask the WG. Clientless endpoints were discussed at length on this list from October to January. Little of that discussion made it into the draft. http://www1.ietf.org/mail-archive/web/nea/current/msg00519.html http://www1.ietf.org/mail-archive/web/nea/current/msg00485.html http://www1.ietf.org/mail-archive/web/nea/current/msg00446.html In addition, the concept of "clientless endpoints" MUST also include endpoints which might be running NEA client software, but which choose to not participate in NEA on the current network. The idea that some clients might not participate in NEA doesn't appear to be addressed in the draft. (A quick scan for "choose" or "choice" or "participate" or "quarantine" yields nothing relevant.) In my mind, this is a major flaw not only with the draft, but with the assumptions that underly it. We have to assume that for the first while that ALMOST ALL endpoints will not be running NEA software. If NEA chooses to ignore that problem completely (as the current draft does), then it's utility will be minimal. As noted in the messages pointed to above, there is a significant amount of endpoint assessment that can be done by using information already available in existing protocols. The NEA operational model MUST address clientless enpoints, it MUST address what decisions can be made about those endpoints, and it MUST address what happens to endpoints that choose to not participate in NEA. > The downside of including clientless is that the NEA Client components > wouldn't be running on the Endpoint which is confusing and would require > us to do a lot of rewording (likely remaining confusing.) I don't understand what the difficulty is. a) clientless endpoints get policy X b) participating endpoints get policy Y. i.e. Clients have a set of attributes indicating current posture. That set MAY be empty. > The upside is > this has better privacy properties and reflects real world situations > where no NEA Client is running on the Endpoint. However some of these > common cases may not be in scope for NEA (visitor who Owns her laptop > and does not wish to consent to an invasive assessment when joining a > network ...) If the NEA documents are silent on those issues, then the design is ignoring clientless endpoints, which makes NEA nearly useless. The requirements document would be made stronger if the authors reviewed the discussions from last fall, and integrated conclusions and scenarios from then into the draft. I've given as much feedback as I can, but I'm reluctant to re-type all of those messages again, and tie them into specific areas of the draft. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Feb 27 05:38:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzis-0007Rj-BQ; Tue, 27 Feb 2007 05:38:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLziq-0007PH-Hh for nea@ietf.org; Tue, 27 Feb 2007 05:38:16 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLzio-000853-Tl for nea@ietf.org; Tue, 27 Feb 2007 05:38:16 -0500 Received: from [10.0.1.60] (alexander.quiconnect.net [213.30.156.62]) by book.deployingradius.com (Postfix) with ESMTP id 55AF9A70B4; Tue, 27 Feb 2007 02:38:05 -0800 (PST) Message-ID: <45E40A0B.5010103@deployingradius.com> Date: Tue, 27 Feb 2007 11:38:03 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Paul Sangster Subject: Re: [Nea] REQ: sections <= 2 References: <2F2D38A4B8346F48A683750A46BAB2110113C552@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8DC0@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DC0@SVL1XCHCLUPIN02.enterprise.veritas.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Paul Sangster wrote: >> 4.Have IETF writing styles changed such that all terms >> defined in the terminology section need to be capitalized? >> If so, then there are instances where this guideline are not >> followed (e.g. the term 'reference model' is not capitalized >> in abstract section vs. rest of document). IMHO, extreme >> usage of capitalized terms, as is the case with this >> document, detracts from the readability. > > We wanted to call out when we were using a defined term vs. the generic > equivalent (roughly equivalent of SHOULD vs should.) Since we use a few > commonly used words (e.g. Message, Component ...) with a special meaning > we thought it was important to be clear what was intended. My suggestion is to avoid re-defining common words. It makes it that much harder to understand the document. (e.g. "That depends on what the meaning of the word 'is' is.") > Policy Attributes describe or reference policies that the Endpoint must > meet to be considered compliant ("must have firewall running at > least version 1.2.3"). These are sent by the NEA Server (will add text > to mention this.) > > Posture Attributes includes Posture information about a requested > Component (Firewall installed, version 1.5, Firewall running, ...) The > Posture Validator compares this information to its policy to determine > compliance. These are sent by the NEA Client. Can we just please use the term "attributes"? It's already understood that attributes are sent by the client for one purpose, and the server for another. Other protocols (DHCP, RADIUS, etc.) do not over-specify terms like this... they just use "attributes". The sheer volume of Capitalized Terms in the document makes me think of the quote "Entities should not be multiplied unnecessarily". > I presume you mean Policy and Compliance Claim Attributes. In some > sense you could argue this but we felt it was important to be more clear > about the different types of attributes as they have differing security, > privacy and operational properties. We found these names very helpful > when writing the spec and hope that after a read of the draft they > aren't confusing. I'm confused as heck by them, and I've been doing posture assessment and policy application in RADIUS & DHCP for a decade. I don't understand why NEA is so much more complicated than other posture assessment and policy application protocols. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Feb 27 09:12:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM33o-00059a-Hs; Tue, 27 Feb 2007 09:12:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM33n-00056f-7Y for nea@ietf.org; Tue, 27 Feb 2007 09:12:07 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM33i-0003bF-QY for nea@ietf.org; Tue, 27 Feb 2007 09:12:07 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=CICR7Cp6eiQVV5I1AgfI61koBIom2K+Pckw0bj+OEIDsTybkgR+xqyrFNWM+xYiU; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.245.6.207] (helo=gw) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HM33d-0002MF-TS; Tue, 27 Feb 2007 09:11:58 -0500 Message-ID: <005a01c75a79$3e95b610$2101a8c0@home.glassey.com> From: "todd glassey" To: "Alan DeKok" , "Paul Sangster" References: <2F2D38A4B8346F48A683750A46BAB2110113C552@G3W0072.americas.hpqcorp.net><5A58F967CBEBBB4A82DF126CF8A9596A025A8DC0@SVL1XCHCLUPIN02.enterprise.veritas.com> <45E40A0B.5010103@deployingradius.com> Subject: Re: [Nea] REQ: sections <= 2 Date: Tue, 27 Feb 2007 06:08:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f5f5f639e0d40a0887f2eeac3476cd0d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.6.207 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org As long as Terms of Art are noted as that, there shouldn't be an issue. Todd ----- Original Message ----- From: "Alan DeKok" To: "Paul Sangster" Cc: Sent: Tuesday, February 27, 2007 2:38 AM Subject: Re: [Nea] REQ: sections <= 2 > Paul Sangster wrote: >>> 4.Have IETF writing styles changed such that all terms >>> defined in the terminology section need to be capitalized? >>> If so, then there are instances where this guideline are not >>> followed (e.g. the term 'reference model' is not capitalized >>> in abstract section vs. rest of document). IMHO, extreme >>> usage of capitalized terms, as is the case with this >>> document, detracts from the readability. >> >> We wanted to call out when we were using a defined term vs. the generic >> equivalent (roughly equivalent of SHOULD vs should.) Since we use a few >> commonly used words (e.g. Message, Component ...) with a special meaning >> we thought it was important to be clear what was intended. > > My suggestion is to avoid re-defining common words. It makes it that > much harder to understand the document. (e.g. "That depends on what the > meaning of the word 'is' is.") > >> Policy Attributes describe or reference policies that the Endpoint must >> meet to be considered compliant ("must have firewall running at >> least version 1.2.3"). These are sent by the NEA Server (will add text >> to mention this.) >> >> Posture Attributes includes Posture information about a requested >> Component (Firewall installed, version 1.5, Firewall running, ...) The >> Posture Validator compares this information to its policy to determine >> compliance. These are sent by the NEA Client. > > Can we just please use the term "attributes"? It's already understood > that attributes are sent by the client for one purpose, and the server > for another. Other protocols (DHCP, RADIUS, etc.) do not over-specify > terms like this... they just use "attributes". > > The sheer volume of Capitalized Terms in the document makes me think > of the quote "Entities should not be multiplied unnecessarily". > >> I presume you mean Policy and Compliance Claim Attributes. In some >> sense you could argue this but we felt it was important to be more clear >> about the different types of attributes as they have differing security, >> privacy and operational properties. We found these names very helpful >> when writing the spec and hope that after a read of the draft they >> aren't confusing. > > I'm confused as heck by them, and I've been doing posture assessment > and policy application in RADIUS & DHCP for a decade. I don't > understand why NEA is so much more complicated than other posture > assessment and policy application protocols. > > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Feb 27 17:31:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAr0-00022w-Uj; Tue, 27 Feb 2007 17:31:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAKb-0004fY-9F for nea@ietf.org; Tue, 27 Feb 2007 16:57:57 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMAIs-0006VJ-UZ for nea@ietf.org; Tue, 27 Feb 2007 16:56:16 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 27 Feb 2007 13:56:10 -0800 X-IronPort-AV: i="4.14,227,1170662400"; d="scan'208"; a="43318271:sNHT79568253" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1RLuAdT018619; Tue, 27 Feb 2007 13:56:10 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1RLu3nN017405; Tue, 27 Feb 2007 13:56:10 -0800 (PST) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:56:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: Section 5 comments Date: Tue, 27 Feb 2007 13:56:04 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C303112AB8@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB2110113C553@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 5 comments Thread-Index: AcdZTUcDOBr2jfMtQ6a6RDSRtgZTNABaDJdw From: "Kaushik Narayan \(kaushik\)" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 27 Feb 2007 21:56:03.0033 (UTC) FILETIME=[12DE6490:01C75ABA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10201; t=1172613370; x=1173477370; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20REQ=3A=20Section=205=20comments |Sender:=20; bh=IuiyeocBDoll9e9t2hvaquq1c58Q+wwoBbSsRyGl41A=; b=xYFnT8K8peDkG9CgQ7V1YuftIlAslrXrN8drh3p69DJiBIvwdf6M+eclN77Cgh3qL6BcFuXC HJl/99hXmi5a2SM4FUWKW/Xm5vbr/PSB0Bq9BWoN4AKWh+RYGOf6BT73; Authentication-Results: sj-dkim-8; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Mauricio, Thanks for your comments. Please find my reply inline. -----Original Message----- From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 Sent: Sunday, February 25, 2007 6:25 PM To: nea@ietf.org Subject: [Nea] REQ: Section 5 comments Several comments/questions about section 5 [Reference Model]: 1. Meta-comment: The model seems to assume that an endpoint consists of only one processing entity (OS, hardware, etc.). It's unclear how the model and the adjunct requirements may need to get modified in light of rising popularity in system virtualization. For example, it likely that multiple posture broker clients and posture transport clients will exist on single hardware system that's been virtualized into multiple systems. I'd say additional thought is necessary in this area or we just punt and explicitly say that it's out of scope at this time. The endpoint necessarily translates to a single hardware entity, the definition (host computing device) might be misleading and will require some editing. The definition of the endpoint is actually in terms how the network views the device, i.e. entities accessing the network using different IP addresses. A virtualized system would typically comprise of several endpoints. 2. Meta-comment: Section 9 describes several suggestions on how to introduce user facilities to manage privacy. In that section there's no specific guidance on which components should implement the suggested privacy enhancements. If not in section 9, wouldn't it be useful to assign the privacy enhancements to the model/components described in section 5? For example, I could envision seeing the posture collectors and posture broker client sharing responsibilities in proving a user the necessary UI and privacy policy management capabilities described in section 9. =20 The privacy considerations largely focus on implementation guidelines to address privacy concerns; the Reference Model is focussed on the functional decomposition and it may not be right section to introduce implementation considerations. 3. Meta-comment: The model describes the existence of protocols between like layers (e.g. posture collector <--PA--> posture validator, posture broker client <--PB--> posture broker server), but provides no description as to what happens between different layers (posture collector <-> posture broker). I suspect that there's an unwritten assumption that different layers may communicate using APIs. If so, I suggest that at a minimum there be some suggestion on how different layers may be communicating (e.g. APIs) and noting that such work is out of scope for the current WG charter (and IETF in general).=20 Side note: Section 5.1.2.2 states that validators may be physically remote to the server. Doesn't this particular situation give rise to yet another protocol for the NEA model to denote? I can imagine the existence of a PV (Posture Validator) protocol between a remote posture validator and a posture broker server. Even though the current WG charter precludes working on any protocol other than PA and PB, we should nonetheless strive for completeness in the description of the model.=20 4. Meta-comment: The document introduction (section 1.0) describes the existence of an enforcement entity to enforce the final admission decision. Although I understand that mechanisms and protocols for enforcement are out of scope, shouldn't the NEA model diagram and description at least acknowledge that an enforcement entity exists? There should be a general goal of having a comprehensive ENA model, even if complete treatment of all components and protocols are not currently within NEA charter. The above two items were deemed out-of-scope at the last IETF as mentioned by Paul. =20 5. Section 5.0: Discussion of reference model includes statement: "This model is provided to establish a context for the discussion of requirements and may not directly map to any particular product or deployment architecture." This statement seems to contradict the statement made in the abstract that the NEA reference model is based on the models used by CNAC, NAP and TNC. =20 6. Section 5.1.1.1, last paragraph: From an interoperability perspective NEA should evaluate mandating a minimum amount of functionality so as to improve the odds of interoperable implementations. Or at a minimum there should be some form of signaling introduced into the protocol to provide for component capability advertisement.=20 I think plan was to define a core schema, i.e. a baseline set of attributes that is mandatory to support for every NEA client/server. Are you suggesting that protocol have some mechanism to advertise vendor supported plugins to determine whether NEA client can interoperate with the NEA server. 7. Section 5.1.1.2, first paragraph, second sentence: "...forwarding the request to the appropriate Posture Collectors." This sentence sounds like a request always goes to multiple collectors. I don't believe this is always the case, or is it? =20 8. Section 5.1.1.2, first paragraph, third sentence: "The Posture Broker Client also multiplexes the responses from the Posture Collector..." This sentence doesn't acknowledge that there may be one or more posture collectors. Consider changing to "...multiplexes the responses from Posture Collector(s)..." 9. Section 5.1.1.3 mentions that there may be more than one posture transport client on an endpoint. I suggest updating the diagram of the model detailing this fact (e.g. add "(1...n)" to posture transport client block as was done for posture collector). Furthermore, it'd be useful to describe why multiple transport clients may be necessary. =20 10. Section 5.1.2.1 mentions that a posture validator may be located on a separate server from the posture server. It goes on to say that the server may have to with both local and remote validators. One can assume that in the instance=20 11. Section 5.1.2.2 describes as one of the roles being, "Communicating with remote Posture Validators and providing cryptographic protection for this communication." It's unclear to me what this exactly means. The broker server doesn't have any direct relationships with a posture validator, or does it? Furthermore, it's not clear at what level the cryptographic protection is being provided. In section 5.1.1.3 (about posture transport client) it state clearly that its role is to protect the message dialog. I suggest the same level of clarity for server broker's role. You are right. This text is confusing since we are not defining protocols between the Posture Broker Server and Posture Validators. The cryptographic protection is actually provided by encryption at the PA layer and not by the Posture Broker Server. I think we can delete this sentence. 12. Section 5.1.2.2 - Is it not the role of the posture broker server to also establish the overall compliance decision for an endpoint? Currently the document only assigns the generation of the global posture decision. If not the broker server, which component generates the overall compliance decision? Or is the global posture decision in fact the compliance decision? I'm confused. 13. Section 5.1.2.3 - Why may there be more than one posture transport server in a particular NEA server? If there are truly multiple posture transport servers, then the NEA model diagram should be updated to reflect this possibility. See comment #8. 14. Section 5.1.2.3 - The statement "Providing cryptographic protection for Posture information." is not as clear as the one used for the posture transport client. For the posture transport client the described role is protection of message dialog. It's probably the same for the transport server and should be designated as such in the document.=20 15. Section 5.3.1 - I sense there is at some level some relationship between the attributes sent by a NEA server (i.e. requests) and those sent by a NEA client (i.e. responses). For example, isn't it the case that request attributes always and only elicit posture attributes as a response? Likewise, couldn't the same be said of policy attributes and compliance claim attributes? If so, it may be useful to highlight these relationships to make the protocol easier to understand.=20 Agree, as Paul pointed we will work to add this. 16. Section 5.3.2 - It's unclear to me to what level the remediation attributes will get defined. On one hand the intro to this section (5.3) states that NEA WG will define a standard set of attributes. By the same token other parts of the document (e.g. section 3.1 - scope) state the standard protocols for remediation are out of scope. In defining remediation attributes are we not inadvertently defining a standard protocol for remediation?=20 Not really, we are merely providing a mechanism to carry remediation instructions, for e.g. this may be a URL that might redirect a client to a remediation server. The actual process & protocols for remediation are still out of scope. Regards, kaushik NITS a. Misplaced period in last sentence of section 5. [Reference model]. Period goes outside parenthesis bracket.=20 b. Misplaced commas and periods in first sentence of 5.1.1.1 c. Misplaced period in last sentence of second paragraph of section 5.1.1.1. Same disposition as NIT 3a. d. Missing period on second bullet of section 5.1.1.2 e. Why is Message Dialog capitalized? See comment 7a. f. Change "Posture Transport Clients" to "Posture Transport Client" in section 5.1.1.3, first paragraph, last sentence. -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- =20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Feb 27 20:31:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMDfR-00028i-40; Tue, 27 Feb 2007 20:31:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMDfP-00028P-Hl for nea@ietf.org; Tue, 27 Feb 2007 20:31:39 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMDfL-0003Or-R0 for nea@ietf.org; Tue, 27 Feb 2007 20:31:39 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Feb 2007 17:31:36 -0800 X-IronPort-AV: i="4.14,227,1170662400"; d="scan'208,217"; a="467449040:sNHT145094008" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1S1VZrp018485 for ; Tue, 27 Feb 2007 17:31:35 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1S1VYUw026673 for ; Tue, 27 Feb 2007 17:31:34 -0800 (PST) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 17:31:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Feb 2007 17:27:07 -0800 Message-ID: <08A9A3213527A6428774900A80DBD8D8038EFCB7@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA requirements draft comments Thread-Index: Acda14+CQJ98/aPZQoOxWaafDVKDZA== From: "Nancy Winget \(ncamwing\)" To: X-OriginalArrivalTime: 28 Feb 2007 01:31:34.0695 (UTC) FILETIME=[2EBD6B70:01C75AD8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=28947; t=1172626295; x=1173490295; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ncamwing@cisco.com; z=From:=20=22Nancy=20Winget=20\(ncamwing\)=22=20 |Subject:=20NEA=20requirements=20draft=20comments |Sender:=20; bh=THlJU2Z5x750G5AsyLrkKa1cyUUlE6cf6mkrpNE0D24=; b=RWzD5xbmsu+5jMau2iCY6cU+UB9yfE9QeuLveL0c7cxq1exsurkdF4vtifZ6bY7DrYGeE7PN cJsTQRiKUptjCrqKw3Qd+DsYP3NHi6hNLOeOqSa2eieRht3KJ0j5KqXg; Authentication-Results: sj-dkim-2; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 835ad9b9deb0975ba747bfa9d7f1aef1 Subject: [Nea] NEA requirements draft comments X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2008282123==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============2008282123== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75AD8.2EACCF9C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75AD8.2EACCF9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I reviewed the requirements and security considerations of the NEA requirements draft and have some comments below: =20 General: - the terms Client and NEA Client, are used interchangeably; only one term should be chosen and used consistantly. Similary for Server and NEA Server. =20 =20 Section 2. Terminology - Should add the following terms as they are used throughout the draft: Validator (or Posture Validator and use only one of these terms), NEA Client, NEA Server, NEA Component - consider adding one or two terms for: User, Owner, Deployer, Administrator - Policy: there is much mention of the general term "policy" which at times is a configuration option, at times a set of "Policy Attributes" and at times something else, that needs to be clarified and defined in this section. =20 Section 7.1 Common Protocol Requirements - the protocol requirements put forth imply that there is a predefined means by which the client and server know how to reach each other. This could be implied or also assumed by the underlying protocol, but is not mentioned in either the requirements, assumptions or considerations sections. While there is mention to this in the architecture section, there should be more clear mention as to such assumptions in either Section 7 or Section 8 as well. - while the individual requirements for the PA, PB and PT protocols call out for confidentiality and integrity, the common section does not. While C-4 speaks to protection against active, passive and replay attacks, there is no mention to forgery or eavesdropping attacks? =20 =20 Section 7.4 Posture Transport (PT) Protocol Requirements - Should PT-5 also include retransmissions? =20 Section 8.1 Trust - This paragraph is too leading and can be construed to attempt to impose further security requirements versus a descriptive statement to assert that the trustworthiness of the attribute contents is beyond the scope of this body. Further the security requirements imposed on the PA, PB and PT are to establish trust between the NEA Client and NEA Server but does not assert trust of the Endpoint hosting the NEA Client. My suggestion is to reword the first paragraph of this section to something like: "Network Endpoint Assement enables NEA Clients and NEA Servers to communicate Posture information that is assessed by Posture Validators. The trust relationship established between the NEA Client and NEA Server is used to securely exchange attributes but is not intended to provide assuranses to the trustworthiness of the Endpoint." =20 Section 8.1.1 Client Components - 1st sentence of the first paragraph should read: "For NEA to properly operate, the NEA Client component of the Endpoint needs to be trusted to accurately represent the requested security Posture of the Endpoint to the NEA Server." - it is not clear to me why the rest of this first paragraph (e.g. 2nd sentence to end of paragraph) is needed? If the point is "The trustworthiness of the contextual information of the attributes themselves is beyond the scope of this draft." then it should just state that and removed the rest of the text. =20 - The 2nd paragraph should also include that there must be some inherent trust between the NEA Server with the NEA Client that is doing the comparison and effective compliance validation. =20 - The 3rd paragraph should define what is meant by "User or Owner" policy. I assume it is policy configured at the Endpoint based on a particular User identity? =20 Section 8.1.2 Network Communications - The last paragraph of this section states a rationale for requiring confidentiality, integrity and replay protection and should be transcribed as such. It currently reads as being too passive, where the requirements posted in Section 7 impose some of these protections as a MUST. My suggestion is to state that NEA must guard against such attacks by providing confidentiality, integrity and replay protection minimally (or as a MUST) for PA and as a SHOULD for PT. =20 Section 8.1.3 Server Components - Shouldn't this section precede 8.1.2? - Only the first and last sentence of the second paragraph is needed....the middle ones seem superfluous. - The last paragraph reads squishy as well, especially the last sentence. I presume by "different systems", it is intended to say "the components physically reside in different hosts". The last sentense should be more direct in stating "When there is physical separation, the communications between the NEA Server components must ensure that the PB Session and PA Message Dialogs are resistant to active and passive attacks, in particular, guarded against eavesdropping, forgery and replay." =20 Section 8.2 Overlapping protections - I would not exactly call the protections as overlapping, as each mechanism and protocol had its own security requirements. While it may be true that deployments may not wish to afford the costs in security every layer and stack for NEA, I would not construe them as "overlapping". A more appropriate title would be "Protection Policy" - In some instances, especially when the Posture Validator is resident in the NEA Server, it may be acceptable to only encrypt the transport, but in general, such assumptions can not be made. Thus, I have a problem with this section as it seems to make assertions that this is generally acceptable. =20 - This section should state that consideration for Policy configuration to allow for the relaxation of protection, say, at the PA when assurances are afforded by the PT may be allowed. However, care must be taken to assure that proper protection is provided for that particular deployment to meet the security goals of the NEA charter and requirements. =20 Section 8.3.1 MiTM - This, like most of the security sections are too wordy. Mutual authentication of the PT link doesn't really guard against a MitM as the attacker can still listen in on the dialog. It is the protection of the transport itself to guard against any injection such as forgery, replay or any packet injection/spoofing is the consideration to be stated as a requirement. Furthermore, to disable a MitM from discerning the content of the information being passed, confidentiality must also be considered to guard against eavesdropping; but this latter one, isn't really considered a MitM attack. - The notion of establishing mutual authentication is a good one, but is not one for MiTM but rather to ensure that only authorized links between NEA Server and NEA Client are established. Perhaps that should be the focus of this section as succeeding sections already describe the need for confidentiality, integrity and replay protection. =20 Sections 8.3.2, 8.3.3 and 8.3.4 could be better summarized into one section that describes the different protections: confidentiality, integrity and replay to guard against the different attacks. They currently seem wordy and somewhat redundant as they are described in more than one section. =20 Section 9 Privacy Considerations - As this is a requirement specification, this section could also be shorted to only list the requirement considerations. There are two main points that need to be described in this section: (1) As privacy issues may be regulated and governed by enterprises, institutions and even governments users may be restricted to software or even networks based on such regulation. (2) Configuration management and control of an endpoint may be administered by the physical user but constrained to the privacy guidelines as regulated by the enterprise and/or government. There is other text mentioning scope of WG and what NEA technology enables that need not be (redundantly) described here. =20 Section 9.1 Implementation Considerations - this section again, seems overly wordy...also, its focus is more towards NEA Client implementation considerations; suggest to rename the section as such. - it is not clear what is meant by a user to control which networks.....is the user the one that is configuring the NEA solution deployments? Would it be better to refer to the 'administrator' versus a 'user' especially as there is mention of "per-User" access which can be construed as a NEA Client user or as a administrator controlling access? - 'opt-in' policy? Not sure exactly what this means? Enable use of NEA protocols as a whole? or to particular attributes? - I am somwhat confused to who "user" and "Owner" and "User policies" refer to.....these roles need to be clearly defined and the terms used consistently. =20 Section 9.2 Minimizing Attribute Disclosure - the terms "user" "owner" and "deployer" seem to be used inconsistantly to sometimes means the "one" configuring the full deployment, sometimes the "one" using the "endpoint" or the "tag" used to apply "per-User" policy.....and is somewhat confusing. Please add a subset of these in the Terminology section and use them throughout the specification consistantly. - This section is somewhat confusing as it's now clear the direction of policy assessment, or the notion of "policy"? For instance: - this section implies that a "policy" is defined by a "set of attributes" but is not explicitly clarified? =20 - this section implies that there is "policy" at the Endpoint which can limit the information that is provided to the NEA Server? Why couldn't this be negotiated between Client and Server? - these seem to describe different mechanisms for realizing one model? That is, the model where the client is provided "policy" of which attributes it may share with the Server to serve as a filter. - This last paragraph implies that only 1 privacy filter is needed? What about an Endpoint that is mobile and may need to adhere to different privacy policies based on government regulations? (or Inside vs. Outside an enterprise?) =20 Regards, Nancy. ------_=_NextPart_001_01C75AD8.2EACCF9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I = reviewed the=20 requirements and security considerations of the NEA requirements draft = and have=20 some comments below:
 
General:
    -=20 the terms Client and NEA Client, are used interchangeably; only one = term=20 should be chosen and used consistantly.  Similary for Server and = NEA=20 Server.
   =20
 
Section 2.=20 Terminology
    -=20 Should add the following terms as they are used throughout the draft: = Validator=20 (or Posture Validator and use only one of these terms), NEA Client, NEA = Server,=20 NEA Component
    -=20 consider adding one or two terms for: User, Owner, Deployer,=20 Administrator
    -=20 Policy:  there is much mention of the general term "policy" which = at times=20 is a configuration option, at times a set of "Policy Attributes" and at = times=20 something else, that needs to be clarified and defined in this=20 section.
 
Section 7.1 Common=20 Protocol Requirements
    -=20 the protocol requirements put forth imply that there is a predefined = means by=20 which the client and server know how to reach each other.  This = could be=20 implied or also assumed by the underlying protocol, but is not mentioned = in=20 either the requirements, assumptions or considerations sections.  = While=20 there is mention to this in the architecture section, there should be = more clear=20 mention as to such assumptions in either Section 7 or Section 8 as=20 well.
    -=20 while the individual requirements for the PA, PB and PT protocols call = out for=20 confidentiality and integrity, the common section does not.  While = C-4=20 speaks to protection against active, passive and replay attacks, there = is no=20 mention to forgery or eavesdropping attacks?
 
 
Section 7.4 Posture=20 Transport (PT) Protocol Requirements
    -=20 Should PT-5 also include retransmissions?
   
Section 8.1=20 Trust
    -=20 This paragraph is too leading and can be construed to attempt to impose = further=20 security requirements versus a descriptive statement to assert that the=20 trustworthiness of the attribute contents is beyond the scope of this=20 body.  Further the security requirements imposed on the PA, PB and = PT are=20 to establish trust between the NEA Client and NEA Server but does not = assert=20 trust of the Endpoint hosting the NEA Client.  My suggestion is to = reword=20 the first paragraph of this section to something = like:
    "Network Endpoint Assement enables NEA Clients and NEA Servers = to=20 communicate Posture information that is assessed by Posture=20 Validators.  The trust relationship established between the NEA = Client and=20 NEA Server is used to securely exchange attributes but is not intended = to=20 provide assuranses to the trustworthiness of the = Endpoint."
 
Section 8.1.1 Client=20 Components
    -=20 1st sentence of the first paragraph should read: "For NEA to properly = operate,=20 the NEA Client component of the Endpoint needs to be trusted to=20 accurately represent the requested security Posture of the Endpoint to = the NEA=20 Server."
    -=20 it is not clear to me why the rest of this first paragraph (e.g. 2nd = sentence to=20 end of paragraph) is needed?  If the point is "The trustworthiness = of the=20 contextual information of the attributes themselves is beyond the scope = of this=20 draft." then it should just state that and removed the rest of the=20 text.
 
    -=20 The 2nd paragraph should also include that there must be some inherent = trust=20 between the NEA Server with the NEA Client that is doing the = comparison and=20 effective compliance validation.
 
    -=20 The 3rd paragraph should define what is meant by "User or Owner" = policy.  I=20 assume it is policy configured at the Endpoint based on a particular = User=20 identity?
 
Section 8.1.2=20 Network Communications
    -=20 The last paragraph of this section states a rationale for requiring=20 confidentiality, integrity and replay protection and should be = transcribed as=20 such.  It currently reads as being too passive, where the = requirements=20 posted in Section 7 impose some of these protections as a MUST.  My = suggestion is to state that NEA must guard against such attacks by = providing=20 confidentiality, integrity and replay protection minimally (or as a = MUST) for PA=20 and as a SHOULD for PT.
 
Section 8.1.3 Server=20 Components
    -=20 Shouldn't this section precede 8.1.2?
    -=20 Only the first and last sentence of the second paragraph is = needed....the middle=20 ones seem superfluous.
    -=20 The last paragraph reads squishy as well, especially the last = sentence.  I=20 presume by "different systems", it is intended to say "the components = physically=20 reside in different hosts".  The last sentense should be more = direct in=20 stating "When there is physical separation, the communications between = the NEA=20 Server components must ensure that the PB Session and PA Message Dialogs = are=20 resistant to active and passive attacks, in particular, guarded against=20 eavesdropping, forgery and replay."
 
Section 8.2=20 Overlapping protections
    -=20 I would not exactly call the protections as overlapping, as each = mechanism and=20 protocol had its own security requirements.  While it may be true = that=20 deployments may not wish to afford the costs in security every layer and = stack=20 for NEA, I would not construe them as "overlapping".  A more = appropriate=20 title would be "Protection Policy"
    -=20 In some instances, especially when the Posture Validator is resident in = the NEA=20 Server, it may be acceptable to only encrypt the transport, but = in=20 general, such assumptions can not be made.  Thus, I have a problem = with=20 this section as it seems to make assertions that this is generally=20 acceptable. 
    -=20 This section should state that consideration for Policy configuration to = allow=20 for the relaxation of protection, say, at the PA when assurances are = afforded by=20 the PT may be allowed.  However, care must be taken to assure that = proper=20 protection is provided for that particular deployment to meet the = security goals=20 of the NEA charter and requirements.
 
Section 8.3.1=20 MiTM
    -=20 This, like most of the security sections are too wordy.  Mutual=20 authentication of the PT link doesn't really guard against a MitM as the = attacker can still listen in on the dialog.  It is the protection = of the=20 transport itself to guard against any injection such as forgery, replay = or any=20 packet injection/spoofing is the consideration to be stated as a=20 requirement.  Furthermore, to disable a MitM from discerning the = content of=20 the information being passed, confidentiality must also be considered to = guard=20 against eavesdropping; but this latter one, isn't really = considered a=20 MitM attack.
    -=20 The notion of establishing mutual authentication is a good one, but is = not one=20 for MiTM but rather to ensure that only authorized links between NEA = Server and=20 NEA Client are established.  Perhaps that should be the focus of = this=20 section as succeeding sections already describe the need for = confidentiality,=20 integrity and replay protection.
 
Sections 8.3.2,=20 8.3.3 and 8.3.4 could be better summarized into one section that = describes the=20 different protections: confidentiality, integrity and replay to guard = against=20 the different attacks.  They currently seem wordy and somewhat = redundant as they are described in more than one = section.
 
Section 9=20 Privacy Considerations
    - As this is a = requirement=20 specification, this section could also be shorted to only list=20 the requirement considerations.   There are two main points that = need to be=20 described in this section: (1) As privacy issues may be regulated and = governed=20 by enterprises, institutions and even governments users may be = restricted to=20 software or even networks based on such regulation.  (2) = Configuration=20 management and control of an endpoint may be administered by the = physical user=20 but constrained to the privacy guidelines as regulated by the enterprise = and/or=20 government.  There is other text mentioning scope of WG and what = NEA=20 technology enables that need not be (redundantly) described = here.
 
Section 9.1=20 Implementation Considerations
    -=20 this section again, seems overly wordy...also, its focus is more towards = NEA=20 Client implementation considerations; suggest to rename the section as=20 such.
    -=20 it is not clear what is meant by a user to control which networks.....is = the=20 user the one that is configuring the NEA solution deployments?  = Would it be=20 better to refer to the 'administrator' versus a 'user' especially as = there is=20 mention of "per-User" access which can be construed as a NEA Client user = or as a=20 administrator controlling access?
    -=20 'opt-in' policy?  Not sure exactly what this means?  Enable = use of NEA=20 protocols as a whole?  or to particular = attributes?
    -=20 I am somwhat confused to who "user" and "Owner" and "User policies" = refer=20 to.....these roles need to be clearly defined and the terms used=20 consistently.
 
Section 9.2=20 Minimizing Attribute Disclosure
    -=20 the terms "user" "owner" and "deployer" seem to be used inconsistantly = to=20 sometimes means the "one" configuring the full deployment,  = sometimes the=20 "one" using the "endpoint" or the "tag" used to apply "per-User" = policy.....and=20 is somewhat confusing.  Please add a subset of these in the = Terminology=20 section and use them throughout the specification=20 consistantly.
    -=20 This section is somewhat confusing as it's now clear the direction of = policy=20 assessment, or the notion of "policy"?  For = instance:
       =20 - this section implies that a "policy" is = defined by a=20 "set of attributes" but is not explicitly clarified?  =
       =20 - this section implies that there is = "policy" at the=20 Endpoint which can limit the information that is provided to the NEA=20 Server?  Why couldn't this be negotiated between Client and=20 Server?
       =20 - these seem to describe different = mechanisms for=20 realizing one model?  That is, the model where the client is = provided=20 "policy" of which attributes it may share with the Server to serve as a=20 filter.
    -=20 This last paragraph implies that only 1 privacy filter is needed?  = What=20 about an Endpoint that is mobile and may need to adhere to different = privacy=20 policies based on government regulations? (or Inside vs. Outside an=20 enterprise?)
 
Regards,
  =20 Nancy.
------_=_NextPart_001_01C75AD8.2EACCF9C-- --===============2008282123== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============2008282123==--