From nea-bounces@ietf.org Wed Jun 06 19:40:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw56f-0005e6-Sz; Wed, 06 Jun 2007 19:40:01 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1Hw56e-0005dq-A5 for nea-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 19:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw56b-0005dP-9N for nea@ietf.org; Wed, 06 Jun 2007 19:39:57 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw56a-0000re-KU for nea@ietf.org; Wed, 06 Jun 2007 19:39:57 -0400 Received: from tus1opsmtapin02.ges.symantec.com ([192.168.214.44]) by extu-mxob-2.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1Hw56Z-00006l-W3 for nea@ietf.org; Wed, 06 Jun 2007 16:39:56 -0700 Received: from reserved-155-64-230-19.ges.symantec.com ([155.64.230.19] helo=TUS1XCHECNPIN02.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1Hw56Z-0007t0-Tk for nea@ietf.org; Wed, 06 Jun 2007 16:39:55 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN02.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 16:39:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Jun 2007 16:39:54 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder to review the -02 I-D thread-index: Aceok/wtoM6gGQy6QxuMJkStDHZscw== From: "Paul Sangster" To: X-OriginalArrivalTime: 06 Jun 2007 23:39:55.0584 (UTC) FILETIME=[FCA77400:01C7A893] X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAAAWluYm94AG5lYUBpZXRmLm9yZwA= X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Nea] Reminder to review the -02 I-D 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="===============0204200217==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0204200217== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A893.FC426CCB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A893.FC426CCB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just wanted to remind the WG that we're coming up on the milestone to issue the next revision of the I-D which will be the WGLC candidate, so now is a great time for comments. We would like to encourage reviews of the I-D prior to June 22nd so we will have time to improve the spec prior to the July revision milestone and Chicago meeting. =20 As you know, the current draft can be found at: http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt =20 This version largely reflects discussions from the mailing list and the Prague meeting. The changes in -02 include: o Mention of quarantining during remediation o Change title to be more broad then just requirements o Removal of Policy and Compliance Claim attribute types - Removal of the use case example where Policy attributes are sent instead of Request attributes o Changed PB cryptographic protection requirement (during NEA selection) to MAY o Mention the scope of the posture sent by NEA Client based on its operational domain only - Covers NAT device and virtualized endpoint cases o Less emphasis on attribute types (more on type of message) o No mention of 3rd party providing posture information for clientless endpoints o No longer capitalize terminology defined which are commonly used words o Addressed some clarification issues from alias o Describe PA and PB as lightweight messaging protocols riding on top of PT =20 Paul Sangster NEA Design Team Chair =20 =20 ------_=_NextPart_001_01C7A893.FC426CCB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just = wanted to=20 remind the WG that we're coming up on the milestone to issue the next = revision=20 of the I-D which will be the WGLC candidate, so now is a great time = for=20 comments.  We would like to encourage reviews of the I-D prior = to June=20 22nd so we will have time to improve the spec prior to the July = revision=20 milestone and Chicago meeting.
 
As you = know, the=20 current draft can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02= .txt
 
This = version largely=20 reflects discussions from the mailing list and the Prague meeting.  = The=20 changes in -02 include:
  = o =20 Mention of quarantining during remediation
  = o =20 Change title to be more broad then just requirements
  = o =20 Removal of Policy and Compliance Claim attribute = types
       &nbs= p; -=20 Removal of the use case example where Policy attributes are sent instead = of=20 Request attributes
  o =20 Changed PB cryptographic protection requirement (during NEA selection) = to=20 MAY
  = o =20 Mention the scope of the posture sent by NEA Client based on its = operational=20 domain only
       &nbs= p; -=20 Covers NAT device and virtualized endpoint cases
  = o  Less=20 emphasis on attribute types (more on type of = message)
  = o  No=20 mention of 3rd party providing posture information for clientless=20 endpoints
  = o  No=20 longer capitalize terminology defined which are commonly used=20 words
  = o =20 Addressed some clarification issues from alias
  = o =20 Describe PA and PB as lightweight messaging protocols riding on top of=20 PT
 
Paul=20 Sangster
NEA = Design Team=20 Chair
 
 
------_=_NextPart_001_01C7A893.FC426CCB-- --===============0204200217== 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 --===============0204200217==-- From nea-bounces@ietf.org Thu Jun 07 12:18:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKgb-0000VU-Jq; Thu, 07 Jun 2007 12:18:09 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1HwKga-0000T7-9c for nea-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKgZ-0000RT-VZ for nea@ietf.org; Thu, 07 Jun 2007 12:18:07 -0400 Received: from mail116.messagelabs.com ([195.245.231.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwKgZ-0003CE-0m for nea@ietf.org; Thu, 07 Jun 2007 12:18:07 -0400 X-VirusChecked: Checked X-Env-Sender: philip.richardson@uk.logicalis.com X-Msg-Ref: server-9.tower-116.messagelabs.com!1181233082!19617269!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [194.72.149.6] Received: (qmail 32343 invoked from network); 7 Jun 2007 16:18:02 -0000 Received: from unknown (HELO uk.logicalis.com) (194.72.149.6) by server-9.tower-116.messagelabs.com with SMTP; 7 Jun 2007 16:18:02 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Jun 2007 17:18:02 +0100 Message-ID: <7754473097338A4AAD61FEE49E7BA9B5073BAADE@ukslexb01.uk.logicalis.local> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Definition of Endpoint - "MAY have an IP address", instead of "with an IP address."? Thread-Index: AcepHX0wsPJjkmTNTG+pD6lCn73VQwAAZXCg References: From: "Philip Richardson" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Subject: [Nea] RE: Definition of Endpoint - "MAY have an IP address", instead of "with an IP address."? 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="===============1127116996==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1127116996== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_005C_01C7A927.CD998EC0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_005C_01C7A927.CD998EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Under "Terminology", the definition of Endpoint is as follows: "Any host computing device that can be connected to a network. This includes: laptops, desktops, servers, cell phone or any device with an IP address." Does this device always have an IP address? Should the definition not state "...MAY have an IP address." For instance in the case of a CNAC deployment, the process may use 802.1x and EAP messages, and access might be denied if the device fails posture assessment. It may have an IP address, but it is not a requirement in all cases. Cheers Phil -----Original Message----- From: nea-request@ietf.org [mailto:nea-request@ietf.org] Sent: 07 June 2007 17:01 To: nea@ietf.org Subject: Nea Digest, Vol 20, Issue 1 Send Nea mailing list submissions to nea@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/nea or, via email, send a message with subject or body 'help' to nea-request@ietf.org You can reach the person managing the list at nea-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Nea digest..." Today's Topics: 1. Reminder to review the -02 I-D (Paul Sangster) ---------------------------------------------------------------------- Message: 1 Date: Wed, 6 Jun 2007 16:39:54 -0700 From: "Paul Sangster" Subject: [Nea] Reminder to review the -02 I-D To: Message-ID: Content-Type: text/plain; charset="us-ascii" Just wanted to remind the WG that we're coming up on the milestone to issue the next revision of the I-D which will be the WGLC candidate, so now is a great time for comments. We would like to encourage reviews of the I-D prior to June 22nd so we will have time to improve the spec prior to the July revision milestone and Chicago meeting. As you know, the current draft can be found at: http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt This version largely reflects discussions from the mailing list and the Prague meeting. The changes in -02 include: o Mention of quarantining during remediation o Change title to be more broad then just requirements o Removal of Policy and Compliance Claim attribute types - Removal of the use case example where Policy attributes are sent instead of Request attributes o Changed PB cryptographic protection requirement (during NEA selection) to MAY o Mention the scope of the posture sent by NEA Client based on its operational domain only - Covers NAT device and virtualized endpoint cases o Less emphasis on attribute types (more on type of message) o No mention of 3rd party providing posture information for clientless endpoints o No longer capitalize terminology defined which are commonly used words o Addressed some clarification issues from alias o Describe PA and PB as lightweight messaging protocols riding on top of PT Paul Sangster NEA Design Team Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/nea/attachments/20070606/913e2abb/attachment- 0001.html ------------------------------ _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea End of Nea Digest, Vol 20, Issue 1 ********************************** ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ------=_NextPart_000_005C_01C7A927.CD998EC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKkTCCBKIw ggOKoAMCAQICEES+DItQACS0EdM2JSVnyYkwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNOTkwNzA5 MTcyODUwWhcNMTkwNzA5MTczNjU4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOBuTCBtjALBgNVHQ8EBAMCAcYw DwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wWAYDVR0fBFEw TzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0G CSqGSIb3DQEBBQUAA4IBAQCxbWFdphp/fKtK5DD8U28lJMbK7eIxXCsO7u5hVW8EPs853sUbSZTk 6yBMtOaeUC5y2Y31qqOzStpWHGCXgNyCoq1KvYor/wsJtMbXIARF5M2AAbq6K27OqteS/uSv6/Qm HRYqf2wwlTcvMxKsf93H0RGMUZiy0KOR0K32n56Dkx4dQrhGr2tm8Jt/6uMDAuUCUcGq1TWdckAD iboxHcUQaFKe36KFxVwIpnjmU0+x6LfTFJ6TpsNk46x+cc28n+kDG8z76awxwa98FXQCmcOyR6bC MmHXx29IJFEnodWHVfJ7j5g9Fp7udbb40I7y88auKFun8PM2F/zDBdPKA0pUMIIF5zCCBM+gAwIB AgIRAOCwIDYQJJxRwAi4VB33H04wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDYxMjA1MDAwMDAw WhcNMDcxMjA1MjM1OTU5WjCB7zE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJT T05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTog aHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2Rv IExpbWl0ZWQxGjAYBgNVBAMTEVBoaWxpcCBSaWNoYXJkc29uMTEwLwYJKoZIhvcNAQkBFiJwaGls aXAucmljaGFyZHNvbkB1ay5sb2dpY2FsaXMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDt09PQNQqA4LQyrocnHfIK0cGnaleoSS/CtPNvClf49UHJIZtaoX4jAErvYf1SiLAJv9bloHPo mmT0hVegk+YnwsxeCJcQVkNzDzrfTMexvqY6NyxYFfvk3fm7M3D33hp+bCFTG70RbtBd74c0VCxr dFDczJSnW2qW5ZR/um/tFwIDAQABo4ICPzCCAjswHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHze Pa4Ebn0wHQYDVR0OBBYEFKJXfK455/AsP7dB38q89OMpOZJ+MA4GA1UdDwEB/wQEAwIFoDAMBgNV HRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9z ZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2NybC5jb21v ZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBK oEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGlj YXRpb25hbmRFbWFpbC5jcmwwgYYGCCsGAQUFBwEBBHoweDA7BggrBgEFBQcwAoYvaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vVVROQWRkVHJ1c3RDbGllbnRDQS5jcnQwOQYIKwYBBQUHMAKGLWh0dHA6 Ly9jcnQuY29tb2RvLm5ldC9VVE5BZGRUcnVzdENsaWVudENBLmNydDAtBgNVHREEJjAkgSJwaGls aXAucmljaGFyZHNvbkB1ay5sb2dpY2FsaXMuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAPfDHQec1r 1jTeAYalgWAOTTkJYsSsaiG4z2OENNbHsyZgjSevOjMv/s2VLn2e8gP7aNtJWlgK0C3PjKe1OISB AUx7EJn+eOlLBP3LXxgOwME2oYXI3B+3HwjRv+uvq47J6Oq7LTyFAYJbAFxnZU/D1kZUzPJCFGfO Uj7yLP3UxlsgyfFmKz9iaIhhHoL5FKhrLc2kC0KCuR6utKjm2iYlbQpsMfswIXOyH1HGSx2gDbjV eqTvskgN6K+XDDueHie3bWQVO/ZxCyNCcIgDWqXMzy4Os69S2yzcgCkxjyLFOVlALIcjSQCWbyw5 acEzVy/NXzN+AbTY4k61DYMAE3okMYID5zCCA+MCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDgsCA2ECScUcAIuFQd 9x9OMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA3MDYwNzE2MTgwMlowIwYJKoZIhvcNAQkEMRYEFEmXqo/ngsbkPuAccfZjnR4JnuzfMGcG CSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIHVBgkrBgEEAYI3 EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3 dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQDgsCA2ECScUcAIuFQd9x9OMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwG A1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVz dC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBF bWFpbAIRAOCwIDYQJJxRwAi4VB33H04wDQYJKoZIhvcNAQEBBQAEgYAVqjXQlpsE4Z3EI0c8khhy bXF/GB2v36UCb1+oJxYWidnhm1rUuQNI5lKtfsSOZO9skh6vppVneo3GjPwOcHXOZ5i90FO1F4Pj 6XXQVbeoSqv+l6Mestni1gZcRBd4qJJBMrlm7P4OKQ5YYBUF8mtV3WP0Xdz3a2MMgmKEyCVhaQAA AAAAAA== ------=_NextPart_000_005C_01C7A927.CD998EC0-- --===============1127116996== 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 --===============1127116996==-- From nea-bounces@ietf.org Thu Jun 07 12:39:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL1G-0004mS-CC; Thu, 07 Jun 2007 12:39:30 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1HwL1F-0004mD-9U for nea-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:39:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL1E-0004lQ-VK for nea@ietf.org; Thu, 07 Jun 2007 12:39:28 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKyq-0003Uk-LH for nea@ietf.org; Thu, 07 Jun 2007 12:37:01 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SDeAX2SejJ9poIFfLBtHaFAKGf8jqmHyUAgOoaJ1n1StxTs9atkSi2Hs5abuEeXI; h=Received:Message-ID:From:To: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 [64.125.79.23] (helo=gw) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HwKyp-0000Bn-G8; Thu, 07 Jun 2007 12:36:59 -0400 Message-ID: <00ea01c7a922$155fca90$174f7d40@home.glassey.com> From: "todd glassey" To: "Philip Richardson" , References: <7754473097338A4AAD61FEE49E7BA9B5073BAADE@ukslexb01.uk.logicalis.local> Subject: Re: [Nea] RE: Definition of Endpoint - "MAY have an IP address", instead of "with an IP address."? Date: Thu, 7 Jun 2007 09:37:02 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79a0c2680f457cd1e586115fe76dc27053350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Philip you are right - the end-point nodes may include systems with a MAC or NW HW address as well, so that DHCP type clients can be supported. Todd Glassey ----- Original Message ----- From: "Philip Richardson" To: Sent: Thursday, June 07, 2007 9:18 AM Subject: [Nea] RE: Definition of Endpoint - "MAY have an IP address",instead of "with an IP address."? > _______________________________________________ > 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 Thu Jun 07 19:21:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRIR-0003cM-LI; Thu, 07 Jun 2007 19:21:39 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1HwRIQ-0003cE-0C for nea-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 19:21:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRIP-0003c6-Mf for nea@ietf.org; Thu, 07 Jun 2007 19:21:37 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwRIO-0000C5-0N for nea@ietf.org; Thu, 07 Jun 2007 19:21:37 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2007 16:21:33 -0700 X-IronPort-AV: i="4.16,397,1175497200"; d="scan'208,217"; a="4547632:sNHT3390697074" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l57NLXpd023422; Thu, 7 Jun 2007 16:21:33 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l57NLGtf026633; Thu, 7 Jun 2007 23:21:33 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 16:21:18 -0700 Received: from 171.69.75.129 ([171.69.75.129]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jun 2007 23:21:12 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 07 Jun 2007 16:21:10 -0700 Subject: Re: [Nea] Reminder to review the -02 I-D From: Kaushik Narayan To: Paul Sangster , Message-ID: Thread-Topic: [Nea] Reminder to review the -02 I-D Thread-Index: Aceok/wtoM6gGQy6QxuMJkStDHZscwAxov/R In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 07 Jun 2007 23:21:18.0728 (UTC) FILETIME=[8D5E8080:01C7A95A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6553; t=1181258493; x=1182122493; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20Kaushik=20Narayan=20 |Subject:=20Re=3A=20[Nea]=20Reminder=20to=20review=20the=20-02=20I-D |Sender:=20; bh=DYbgcbv8Je0Q02DBtQFqtWq5QjdCbt8gIlK7fvnt/fg=; b=c1NXPO+F2S1GEoo/DoKR9NA1b+i0Co2QFnSlpVubtF6ahu7OTufIj8Oir3Lb0/g2vgVPFQns 5FcpWKfnzcTJMbPnaVJi0xPTKnjOqqdeujlCMwPcEQTCji//EweYmnnaTPW5H6YynNL5/MB6JT ZxIWjp2Pi3tG+EXKxs7bMClP0=; Authentication-Results: sj-dkim-1; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 1.6 (+) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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: , Content-Type: multipart/mixed; boundary="===============0076207376==" Errors-To: nea-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0076207376== Content-type: multipart/alternative; boundary="B_3264078070_4415918" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3264078070_4415918 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi All, In addition to comments on the entire draft, we would like to request the W= G to provide input on three sections for which we haven=B9t received a lot of comments. These sections include Section 7 : Requirements Section 8 : Security Considerations Section 9 : Privacy Considerations There was a lot discussion on the WG list about Security & Privacy considerations prior to the Requirements I-D being published. We would like WG members to validate whether Section 8 & Section 9 adequately addresses their comments/issues/concerns. regards, NEA Design Team On 6/6/07 4:39 PM, "Paul Sangster" wrote: > Just wanted to remind the WG that we're coming up on the milestone to iss= ue > the next revision of the I-D which will be the WGLC candidate, so now is = a > great time for comments. We would like to encourage reviews of the I-D p= rior > to June 22nd so we will have time to improve the spec prior to the July > revision milestone and Chicago meeting. > =20 > As you know, the current draft can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt > =20 > This version largely reflects discussions from the mailing list and the P= rague > meeting. The changes in -02 include: > o Mention of quarantining during remediation > o Change title to be more broad then just requirements > o Removal of Policy and Compliance Claim attribute types > - Removal of the use case example where Policy attributes are se= nt > instead of Request attributes > o Changed PB cryptographic protection requirement (during NEA selectio= n) to > MAY > o Mention the scope of the posture sent by NEA Client based on its > operational domain only > - Covers NAT device and virtualized endpoint cases > o Less emphasis on attribute types (more on type of message) > o No mention of 3rd party providing posture information for clientless > endpoints > o No longer capitalize terminology defined which are commonly used wor= ds > o Addressed some clarification issues from alias > o Describe PA and PB as lightweight messaging protocols riding on top = of PT > =20 > Paul Sangster > NEA Design Team Chair > =20 > =20 >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea --B_3264078070_4415918 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Nea] Reminder to review the -02 I-D Hi Al= l,

In addition to comments on the entire draft, we would like to request the W= G to provide input on three sections for which we haven’t received a l= ot of comments. These sections include

Section 7 : Requirements
Section 8 : Security Considerations
Section 9 : Privacy Considerations

There was a lot discussion on the WG list about Security & Privacy cons= iderations prior to the Requirements I-D being published. We would like WG m= embers to validate whether Section 8 & Section 9 adequately addresses th= eir comments/issues/concerns.

regards,
  NEA Design Team


On 6/6/07 4:39 PM, "Paul Sangster" <Paul_Sangster@symantec.com= > wrote:

Just wanted to remind the WG that we're coming up on the milestone to issue= the next revision of the I-D which will be the WGLC candidate, so now is a = great time for comments.  We would like to encourage reviews of the I-D= prior to June 22nd so we will have time to improve the spec prior to the Ju= ly revision milestone and Chicago meeting.
As you know, the current draft can be found at: http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt=

This version largely reflects discussions from th= e mailing list and the Prague meeting.  The changes in -02 include:
  o  Mention of quarantining during remediation
  o  Change title to be more broad then just requirements   o  Removal of Policy and Compliance Claim attribute types<= BR>          - Removal of the use = case example where Policy attributes are sent instead of Request attributes<= BR>   o  Changed PB cryptographic protection requirement (during= NEA selection) to MAY
  o  Mention the scope of the posture sent by NEA Client bas= ed on its operational domain only
         - Covers NAT device a= nd virtualized endpoint cases
  o  Less emphasis on attribute types (more on type of messa= ge)
  o  No mention of 3rd party providing posture information f= or clientless endpoints
  o  No longer capitalize terminology defined which are comm= only used words
  o  Addressed some clarification issues from alias
  o  Describe PA and PB as lightweight messaging protocols r= iding on top of PT
Paul Sangster
NEA Design Team Chair


_______________________________________________
Nea mailing list
Nea@ietf.org
https://www1.ietf.org/mailman/listinfo/nea

 --B_3264078070_4415918-- --===============0076207376== 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 --===============0076207376==-- From nea-bounces@ietf.org Fri Jun 08 15:11:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjsE-0004Zh-Nq; Fri, 08 Jun 2007 15:11:50 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1HwjsD-0004ZC-N8 for nea-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 15:11:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjsD-0004Z0-D8 for nea@ietf.org; Fri, 08 Jun 2007 15:11:49 -0400 Received: from mfnbm1.zonelabs.com ([208.185.174.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwjs7-0003ZC-Vz for nea@ietf.org; Fri, 08 Jun 2007 15:11:44 -0400 Received: from sfex02.ad.checkpoint.com (sfex02.zonelabs.com [209.87.220.71]) by mfnbm1.zonelabs.com (8.12.11/8.12.10/ZL1.2) with ESMTP id l58JBWBs026687; Fri, 8 Jun 2007 12:11:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Reminder to review the -02 I-D Date: Fri, 8 Jun 2007 10:08:18 -0700 Message-ID: <79EEEE28B0432B45BEA63288D90231D7033E59AE@sfex02.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Reminder to review the -02 I-D Thread-Index: Aceok/wtoM6gGQy6QxuMJkStDHZscwAyDl1A References: From: "Matt Hite" To: "Paul Sangster" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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: , Content-Type: multipart/mixed; boundary="===============1273487353==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1273487353== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A9EF.9BE2C93C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A9EF.9BE2C93C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Typo: =20 5.1.1 For example a NAT device might route communications for many=20 systems behind it, but when the NAT device is joining the=20 network its NEA Client is only reports its own posture. =20 [Take out "is only" or "is only reporting its own posture"?] =20 _____ =20 From: Paul Sangster [mailto:Paul_Sangster@symantec.com]=20 Sent: Wednesday, June 06, 2007 4:40 PM To: nea@ietf.org Subject: [Nea] Reminder to review the -02 I-D Just wanted to remind the WG that we're coming up on the milestone to issue the next revision of the I-D which will be the WGLC candidate, so now is a great time for comments. We would like to encourage reviews of the I-D prior to June 22nd so we will have time to improve the spec prior to the July revision milestone and Chicago meeting. =20 As you know, the current draft can be found at: http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt =20 This version largely reflects discussions from the mailing list and the Prague meeting. The changes in -02 include: o Mention of quarantining during remediation o Change title to be more broad then just requirements o Removal of Policy and Compliance Claim attribute types - Removal of the use case example where Policy attributes are sent instead of Request attributes o Changed PB cryptographic protection requirement (during NEA selection) to MAY o Mention the scope of the posture sent by NEA Client based on its operational domain only - Covers NAT device and virtualized endpoint cases o Less emphasis on attribute types (more on type of message) o No mention of 3rd party providing posture information for clientless endpoints o No longer capitalize terminology defined which are commonly used words o Addressed some clarification issues from alias o Describe PA and PB as lightweight messaging protocols riding on top of PT =20 Paul Sangster NEA Design Team Chair =20 =20 ------_=_NextPart_001_01C7A9EF.9BE2C93C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Typo:
 
5.1.1
 For =
example a NAT device might route communications for many=20
    systems behind it, but when the NAT device is joining the=20
    network its NEA Client is only reports its own posture.  =
[Take out "is only"=20 or "is only reporting its own posture"?]

 
From: Paul Sangster = [mailto:Paul_Sangster@symantec.com]=20
Sent: Wednesday, June 06, 2007 4:40 PM
To:=20 nea@ietf.org
Subject: [Nea] Reminder to review the -02=20 I-D

Just wanted to = remind the=20 WG that we're coming up on the milestone to issue the next revision of = the I-D=20 which will be the WGLC candidate, so now is a great time for=20 comments.  We would like to encourage reviews of the I-D prior = to June=20 22nd so we will have time to improve the spec prior to the July = revision=20 milestone and Chicago meeting.
 
As you know, = the current=20 draft can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02= .txt
 
This version = largely=20 reflects discussions from the mailing list and the Prague meeting.  = The=20 changes in -02 include:
  o  = Mention of=20 quarantining during remediation
  o  = Change title=20 to be more broad then just requirements
  o  = Removal of=20 Policy and Compliance Claim attribute types
       &nbs= p; -=20 Removal of the use case example where Policy attributes are sent instead = of=20 Request attributes
  o  Changed=20 PB cryptographic protection requirement (during NEA selection) to=20 MAY
  o  = Mention the=20 scope of the posture sent by NEA Client based on its operational domain=20 only
       &nbs= p; -=20 Covers NAT device and virtualized endpoint cases
  o  = Less=20 emphasis on attribute types (more on type of = message)
  o  = No mention=20 of 3rd party providing posture information for clientless=20 endpoints
  o  = No longer=20 capitalize terminology defined which are commonly used = words
  o  = Addressed=20 some clarification issues from alias
  o  = Describe PA=20 and PB as lightweight messaging protocols riding on top of=20 PT
 
Paul=20 Sangster
NEA Design Team = Chair
 
 
------_=_NextPart_001_01C7A9EF.9BE2C93C-- --===============1273487353== 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 --===============1273487353==-- From nea-bounces@ietf.org Fri Jun 08 15:22:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwk31-0008RA-3x; Fri, 08 Jun 2007 15:22:59 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1Hwk30-0008R5-Jj for nea-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 15:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwk30-0008Qx-AB for nea@ietf.org; Fri, 08 Jun 2007 15:22:58 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwk2y-0003Z6-HC for nea@ietf.org; Fri, 08 Jun 2007 15:22:58 -0400 Received: from tus1opsmtapin01.ges.symantec.com ([192.168.214.43]) by extu-mxob-2.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1Hwk2x-0004CD-Nu; Fri, 08 Jun 2007 12:22:56 -0700 Received: from reserved-155-64-230-20.ges.symantec.com ([155.64.230.20] helo=TUS1XCHECNPIN03.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1Hwk2x-0005nx-Ho; Fri, 08 Jun 2007 12:22:55 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 12:22:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Reminder to review the -02 I-D Date: Fri, 8 Jun 2007 12:22:54 -0700 Message-ID: In-Reply-To: <79EEEE28B0432B45BEA63288D90231D7033E59AE@sfex02.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Reminder to review the -02 I-D thread-index: Aceok/wtoM6gGQy6QxuMJkStDHZscwAyDl1AAClv3PA= References: <79EEEE28B0432B45BEA63288D90231D7033E59AE@sfex02.ad.checkpoint.com> From: "Paul Sangster" To: "Matt Hite" , X-OriginalArrivalTime: 08 Jun 2007 19:22:55.0551 (UTC) FILETIME=[6A6CA4F0:01C7AA02] X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAAAmluYm94AG5lYUBpZXRmLm9yZwBtaGl0ZUB1cy5jaGVja3BvaW50LmNvbQA= X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 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: , Content-Type: multipart/mixed; boundary="===============0717082977==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0717082977== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AA02.69EDC3AF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AA02.69EDC3AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, it should say "its NEA Client would only report its own (local) posture" ________________________________ From: Matt Hite [mailto:mhite@us.checkpoint.com]=20 Sent: Friday, June 08, 2007 10:08 AM To: Paul Sangster; nea@ietf.org Subject: RE: [Nea] Reminder to review the -02 I-D =09 =09 Typo: =20 5.1.1 =09 For example a NAT device might route communications for many=20 systems behind it, but when the NAT device is joining the=20 network its NEA Client is only reports its own posture. =20 [Take out "is only" or "is only reporting its own posture"?] =09 =20 ________________________________ From: Paul Sangster [mailto:Paul_Sangster@symantec.com]=20 Sent: Wednesday, June 06, 2007 4:40 PM To: nea@ietf.org Subject: [Nea] Reminder to review the -02 I-D =09 =09 Just wanted to remind the WG that we're coming up on the milestone to issue the next revision of the I-D which will be the WGLC candidate, so now is a great time for comments. We would like to encourage reviews of the I-D prior to June 22nd so we will have time to improve the spec prior to the July revision milestone and Chicago meeting. =20 As you know, the current draft can be found at: =09 http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt =20 This version largely reflects discussions from the mailing list and the Prague meeting. The changes in -02 include: o Mention of quarantining during remediation o Change title to be more broad then just requirements o Removal of Policy and Compliance Claim attribute types - Removal of the use case example where Policy attributes are sent instead of Request attributes o Changed PB cryptographic protection requirement (during NEA selection) to MAY o Mention the scope of the posture sent by NEA Client based on its operational domain only - Covers NAT device and virtualized endpoint cases o Less emphasis on attribute types (more on type of message) o No mention of 3rd party providing posture information for clientless endpoints o No longer capitalize terminology defined which are commonly used words o Addressed some clarification issues from alias o Describe PA and PB as lightweight messaging protocols riding on top of PT =20 Paul Sangster NEA Design Team Chair =20 =09 =20 ------_=_NextPart_001_01C7AA02.69EDC3AF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks, it should say "its NEA Client would = only report its=20 own (local) posture"

From: Matt Hite=20 [mailto:mhite@us.checkpoint.com]
Sent: Friday, June 08, = 2007 10:08=20 AM
To: Paul Sangster; nea@ietf.org
Subject: RE: = [Nea]=20 Reminder to review the -02 I-D

Typo:
 
5.1.1
 For =
example a NAT device might route communications for many=20
    systems behind it, but when the NAT device is joining the=20
    network its NEA Client is only reports its own posture.  =
[Take out "is only" or "is only reporting its own=20 posture"?]

 
From: Paul Sangster=20 [mailto:Paul_Sangster@symantec.com]
Sent: Wednesday, June = 06, 2007=20 4:40 PM
To: nea@ietf.org
Subject: [Nea] Reminder = to review=20 the -02 I-D

Just wanted = to remind the=20 WG that we're coming up on the milestone to issue the next revision of = the I-D=20 which will be the WGLC candidate, so now is a great time for=20 comments.  We would like to encourage reviews of the I-D prior=20 to June 22nd so we will have time to improve the spec prior = to the=20 July revision milestone and Chicago meeting.
 
As you know, = the current=20 draft can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02= .txt
 
This version = largely=20 reflects discussions from the mailing list and the Prague = meeting.  The=20 changes in -02 include:
  = o  Mention of=20 quarantining during remediation
  = o  Change=20 title to be more broad then just requirements
  = o  Removal of=20 Policy and Compliance Claim attribute types
       &nbs= p; -=20 Removal of the use case example where Policy attributes are sent = instead of=20 Request attributes
  o =20 Changed PB cryptographic protection requirement (during NEA selection) = to=20 MAY
  = o  Mention=20 the scope of the posture sent by NEA Client based on its operational = domain=20 only
       &nbs= p; -=20 Covers NAT device and virtualized endpoint cases
  = o  Less=20 emphasis on attribute types (more on type of = message)
  = o  No mention=20 of 3rd party providing posture information for clientless=20 endpoints
  = o  No longer=20 capitalize terminology defined which are commonly used=20 words
  = o  Addressed=20 some clarification issues from alias
  = o  Describe=20 PA and PB as lightweight messaging protocols riding on top of=20 PT
 
Paul=20 Sangster
NEA Design = Team=20 Chair
 
 
------_=_NextPart_001_01C7AA02.69EDC3AF-- --===============0717082977== 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 --===============0717082977==-- From nea-bounces@ietf.org Fri Jun 08 15:32:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkC7-0004SD-MR; Fri, 08 Jun 2007 15:32:23 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1HwkC5-0004Qj-Pp for nea-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 15:32:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkC5-0004Qb-GF for nea@ietf.org; Fri, 08 Jun 2007 15:32:21 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwkC4-00079l-Ui for nea@ietf.org; Fri, 08 Jun 2007 15:32:21 -0400 Received: from tus1opsmtapin01.ges.symantec.com ([192.168.214.43]) by extu-mxob-1.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1HwkC4-0007m1-94; Fri, 08 Jun 2007 12:32:20 -0700 Received: from reserved-155-64-230-20.ges.symantec.com ([155.64.230.20] helo=TUS1XCHECNPIN03.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HwkC2-0006cy-1i; Fri, 08 Jun 2007 12:32:18 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 12:32:18 -0700 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] RE: Definition of Endpoint - "MAY have an IP address", instead of "with an IP address."? Date: Fri, 8 Jun 2007 12:32:16 -0700 Message-ID: In-Reply-To: <7754473097338A4AAD61FEE49E7BA9B5073BAADE@ukslexb01.uk.logicalis.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] RE: Definition of Endpoint - "MAY have an IP address", instead of "with an IP address."? thread-index: AcepHX0wsPJjkmTNTG+pD6lCn73VQwAAZXCgADjv8MA= References: <7754473097338A4AAD61FEE49E7BA9B5073BAADE@ukslexb01.uk.logicalis.local> From: "Paul Sangster" To: "Philip Richardson" , X-OriginalArrivalTime: 08 Jun 2007 19:32:18.0086 (UTC) FILETIME=[B9B8AC60:01C7AA03] X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAAAmluYm94AG5lYUBpZXRmLm9yZwBwaGlsaXAucmljaGFyZHNvbkB1ay5sb2dpY2FsaXMuY29tAA== X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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: Philip Richardson [mailto:philip.richardson@uk.logicalis.com]=20 > Sent: Thursday, June 07, 2007 9:18 AM > To: nea@ietf.org > Subject: [Nea] RE: Definition of Endpoint - "MAY have an IP=20 > address",instead of "with an IP address."? >=20 > Hi all, >=20 > Under "Terminology", the definition of Endpoint is as follows: > "Any host computing device that can be connected to a network. This > includes: laptops, desktops, servers, cell phone or any=20 > device with an IP address." >=20 > Does this device always have an IP address?=20 No it might just have a MAC address if it hasn't yet joined the network (pre-DHCP). However the device should have an L2 address and potentially an L3 address. If the WG believes this helps the definition we could add it. > Should the definition not state "...MAY have an IP address." We'll add some text to mention that this means it would have a link layer and possibly an IP layer address. BTW, we reserve the use of 2119 requirements language for the requirements themselves. >=20 > For instance in the case of a CNAC deployment, the process=20 > may use 802.1x and EAP messages, and access might be denied=20 > if the device fails posture assessment. It may have an IP=20 > address, but it is not a requirement in all cases. Agreed the endpoint might have an IP address but we don't assume it does for cases where it hasn't yet joined the network. >=20 > Cheers > Phil >=20 >=20 > -----Original Message----- > From: nea-request@ietf.org [mailto:nea-request@ietf.org] > Sent: 07 June 2007 17:01 > To: nea@ietf.org > Subject: Nea Digest, Vol 20, Issue 1 >=20 > Send Nea mailing list submissions to > nea@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/nea > or, via email, send a message with subject or body 'help' to > nea-request@ietf.org >=20 > You can reach the person managing the list at > nea-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more=20 > specific than "Re: Contents of Nea digest..." >=20 >=20 > Today's Topics: >=20 > 1. Reminder to review the -02 I-D (Paul Sangster) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Wed, 6 Jun 2007 16:39:54 -0700 > From: "Paul Sangster" > Subject: [Nea] Reminder to review the -02 I-D > To: > Message-ID: > =09 > rise.veritas.c > om> > =09 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Just wanted to remind the WG that we're coming up on the=20 > milestone to issue the next revision of the I-D which will be=20 > the WGLC candidate, so now is a great time for comments. We=20 > would like to encourage reviews of the I-D prior to June 22nd=20 > so we will have time to improve the spec prior to the July=20 > revision milestone and Chicago meeting. > =20 > As you know, the current draft can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt > =20 > This version largely reflects discussions from the mailing=20 > list and the Prague meeting. The changes in -02 include: > o Mention of quarantining during remediation > o Change title to be more broad then just requirements > o Removal of Policy and Compliance Claim attribute types > - Removal of the use case example where Policy=20 > attributes are sent instead of Request attributes > o Changed PB cryptographic protection requirement (during NEA > selection) to MAY > o Mention the scope of the posture sent by NEA Client=20 > based on its operational domain only > - Covers NAT device and virtualized endpoint cases > o Less emphasis on attribute types (more on type of message) > o No mention of 3rd party providing posture information=20 > for clientless endpoints > o No longer capitalize terminology defined which are=20 > commonly used words > o Addressed some clarification issues from alias > o Describe PA and PB as lightweight messaging protocols=20 > riding on top of PT > =20 > Paul Sangster > NEA Design Team Chair > =20 > =20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/nea/attachments/20070606/913e2a > bb/attachment- > 0001.html >=20 > ------------------------------ >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 >=20 > End of Nea Digest, Vol 20, Issue 1 > ********************************** >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jun 13 09:14:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HySfi-0002Ng-ED; Wed, 13 Jun 2007 09:14:02 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1HySfe-0002NP-FZ for nea-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 09:13:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HySfe-0002NH-5E for nea@ietf.org; Wed, 13 Jun 2007 09:13:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HySfc-00046D-M8 for nea@ietf.org; Wed, 13 Jun 2007 09:13:58 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Jun 2007 09:13:56 -0400 X-IronPort-AV: i="4.16,416,1175486400"; d="scan'208,217"; a="62625991:sNHT110149830" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5DDDuF3020823; Wed, 13 Jun 2007 09:13:56 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5DDDiBu004087; Wed, 13 Jun 2007 13:13:56 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 09:13:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Reminder to review the -02 I-D Date: Wed, 13 Jun 2007 09:13:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Reminder to review the -02 I-D Thread-Index: Aceok/wtoM6gGQy6QxuMJkStDHZscwFKFWyw From: "Susan Thomson \(sethomso\)" To: "Paul Sangster" , X-OriginalArrivalTime: 13 Jun 2007 13:13:45.0149 (UTC) FILETIME=[ABD246D0:01C7ADBC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9478; t=1181740436; x=1182604436; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20RE=3A=20[Nea]=20Reminder=20to=20review=20the=20-02=20I-D |Sender:=20 |To:=20=22Paul=20Sangster=22=20, =20; bh=5lJW5h4uySUSS+rPh84vrFu1Dwe+3I5xx891yWMMUAg=; b=Aa3Kn4IAottzGUXb/MJVWRNfZOOGltpU0CigJdXzAY2OUKNeAf6G8GAFiU7SLZiMen6TMnAe Eql3CjgKUKx4H+dq3ubz0NDWqKwA8Fy2x+15I5r8V+o6zZkS58J+h2Ot; Authentication-Results: rtp-dkim-1; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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: , Content-Type: multipart/mixed; boundary="===============1547321550==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1547321550== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ADBC.ABB279CA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADBC.ABB279CA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Just to reiterate the request for comments on draft-ietf-nea-requirements-02.txt by June 22nd (see below) so that it can be revised this month.=20 =20 We are fast approaching the I-D cutoff date prior to the next IETF (9 July), and our milestone for making the next version of the draft the candidate for WGLC. =20 Thanks Susan & Steve ________________________________ From: Paul Sangster [mailto:Paul_Sangster@symantec.com]=20 Sent: Wednesday, June 06, 2007 7:40 PM To: nea@ietf.org Subject: [Nea] Reminder to review the -02 I-D =09 =09 Just wanted to remind the WG that we're coming up on the milestone to issue the next revision of the I-D which will be the WGLC candidate, so now is a great time for comments. We would like to encourage reviews of the I-D prior to June 22nd so we will have time to improve the spec prior to the July revision milestone and Chicago meeting. =20 As you know, the current draft can be found at: =09 http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt =20 This version largely reflects discussions from the mailing list and the Prague meeting. The changes in -02 include: o Mention of quarantining during remediation o Change title to be more broad then just requirements o Removal of Policy and Compliance Claim attribute types - Removal of the use case example where Policy attributes are sent instead of Request attributes o Changed PB cryptographic protection requirement (during NEA selection) to MAY o Mention the scope of the posture sent by NEA Client based on its operational domain only - Covers NAT device and virtualized endpoint cases o Less emphasis on attribute types (more on type of message) o No mention of 3rd party providing posture information for clientless endpoints o No longer capitalize terminology defined which are commonly used words o Addressed some clarification issues from alias o Describe PA and PB as lightweight messaging protocols riding on top of PT =20 Paul Sangster NEA Design Team Chair =20 =09 =20 ------_=_NextPart_001_01C7ADBC.ABB279CA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Just to reiterate the request for comments on=20 draft-ietf-nea-requirements-02.txt  by June 22nd (see = below) so that it can be revised this month.=20
 
We are fast approaching the I-D cutoff = date prior to the next IETF (9 July), = and our=20  milestone for making the next version of the draft the = candidate for=20 WGLC.
 
Thanks
Susan &=20 Steve

From: Paul Sangster=20 [mailto:Paul_Sangster@symantec.com]
Sent: Wednesday, June = 06, 2007=20 7:40 PM
To: nea@ietf.org
Subject: [Nea] Reminder = to review=20 the -02 I-D

Just = wanted to=20 remind the WG that we're coming up on the milestone to issue the next = revision=20 of the I-D which will be the WGLC candidate, so now is a great = time for=20 comments.  We would like to encourage reviews of the I-D prior=20 to June 22nd so we will have time to improve the spec prior = to the=20 July revision milestone and Chicago meeting.
 
As = you know, the=20 current draft can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02= .txt
 
This = version=20 largely reflects discussions from the mailing list and the Prague=20 meeting.  The changes in -02 include:
  o =20 Mention of quarantining during remediation
  o =20 Change title to be more broad then just = requirements
  o =20 Removal of Policy and Compliance Claim attribute = types
       &nbs= p; -=20 Removal of the use case example where Policy attributes are sent = instead of=20 Request attributes
  o  Changed PB = cryptographic=20 protection requirement (during NEA selection) to = MAY
  o =20 Mention the scope of the posture sent by NEA Client based on its = operational=20 domain only
       &nbs= p; -=20 Covers NAT device and virtualized endpoint cases
  o =20 Less emphasis on attribute types (more on type of = message)
  o  No=20 mention of 3rd party providing posture information for clientless=20 endpoints
  o  No=20 longer capitalize terminology defined which are commonly used=20 words
  o =20 Addressed some clarification issues from alias
  o =20 Describe PA and PB as lightweight messaging protocols riding on top of = PT
 
Paul = Sangster
NEA = Design Team=20 Chair
 
 
------_=_NextPart_001_01C7ADBC.ABB279CA-- --===============1547321550== 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 --===============1547321550==-- From nea-bounces@ietf.org Wed Jun 20 11:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12Z9-0005K4-Gq; Wed, 20 Jun 2007 11:57:55 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I12Z8-0005Jv-2T for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 11:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12Z7-0005Jn-PE for nea@ietf.org; Wed, 20 Jun 2007 11:57:53 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I12Z5-0005Eo-HT for nea@ietf.org; Wed, 20 Jun 2007 11:57:53 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2007 11:57:50 -0400 X-IronPort-AV: i="4.16,443,1175486400"; d="scan'208"; a="63258630:sNHT1985267168" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5KFvo4p010431 for ; Wed, 20 Jun 2007 11:57:50 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5KFvj5n019671 for ; Wed, 20 Jun 2007 15:57:50 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 11:57:35 -0400 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 Date: Wed, 20 Jun 2007 11:57:34 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments on -02 I-D Thread-Index: AcezU7eFvMfAe+XRS6WgQmZJIaSohg== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 20 Jun 2007 15:57:35.0628 (UTC) FILETIME=[B82294C0:01C7B353] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=138; t=1182355070; x=1183219070; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20Review=20comments=20on=20-02=20I-D |Sender:=20 |To:=20; bh=GeiQg63mQ5F7D4r79ciqrMfoKW7O2YL4C68eJcsZBIY=; b=Ffs/2hH4K6actv9uPC7Qsd/GRc/mlxmGMz7O8fcU9P3DvArbsgl80vxZpk9gXAVhYlW2LUZi mECYl3A4msWHSSoYLFVybjvyWbJG/jTpM4wJsGHVZZjarCpy14cgethA; Authentication-Results: rtp-dkim-2; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Nea] Review comments on -02 I-D 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 In the next few messages, I will send my review comments on the -02 I-D section by section (not necessarily in order). Thanks Susan _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jun 20 11:58:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12Zc-0005Xx-OI; Wed, 20 Jun 2007 11:58:24 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I12Zb-0005Xs-Nq for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 11:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12Zb-0005Xk-EF for nea@ietf.org; Wed, 20 Jun 2007 11:58:23 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I12Zb-0005b7-5C for nea@ietf.org; Wed, 20 Jun 2007 11:58:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2007 11:58:23 -0400 X-IronPort-AV: i="4.16,443,1175486400"; d="scan'208"; a="63258720:sNHT55389862" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5KFwM6D026420 for ; Wed, 20 Jun 2007 11:58:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KFwEBs024266 for ; Wed, 20 Jun 2007 15:58:22 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 11:58:19 -0400 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 Date: Wed, 20 Jun 2007 11:58:18 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Section 5 - Reference model Thread-Index: AcezU9FuXSgCfYq7RB22MFToJ8uq0A== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 20 Jun 2007 15:58:19.0114 (UTC) FILETIME=[D20E04A0:01C7B353] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3024; t=1182355102; x=1183219102; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20Comments=20on=20Section=205=20-=20Reference=20model |Sender:=20 |To:=20; bh=XRdIR7z+kiN6e3lmwa2SDo7YXQBGKZOSHojMoJJuaBs=; b=Z/Klbj694TB5wbtam/XW2wqIs0Vfzj4ZUr9cAl/wbImRfSpD+xQK26r3PFiyDTXrska7ZQ2X jIg5edPPsLUwX4xQFF9sofmykLoquzrMg4PN/odp9h0nKUV6u2VlaUjv; Authentication-Results: rtp-dkim-1; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [Nea] Comments on Section 5 - Reference model 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 Section 5 First para, pg 10-11:=20 Ist para, 3rd and 4th sentence: A few edits to make encapsulation more explicit: ... The model includes the major components of the NEA Client and Server and their=20 relationships, as well as the protocols they use to communicate at various levels.=20 While the diagram shows 3 layered protocols, it's envisioned that PA is encapsulated within PB which in turn is encapsulated in PT. PA is a thin, message wrapper around a set of attributes. PB is primarily a lightweight message batching protocol, and may carry PB-layer attributes. PT transports PA and PB.=20 Section 5.1.1: NEA Client Add that the NEA client is also responsible for receiving posture compliance results and any recommendations for remediation. I think reference to endpoints without a client should be omitted since this is not in scope. Section 5.1.1.1: Posture Collector 1st sentence, 1st para, p12 does not read well. Change to: The Posture Collector is the component that is responsible for responding to requests for posture information from the NEA server. The Posture Collector is also responsible for receiving assessment decisions and remediation instructions. =20 Last sentence, 1st para, p13: Move earlier in paragraph after the above. i.e. Posture Collectors may also be capable of evaluating rules and=20 asserting posture decisions. =20 2nd para, p13: Re identification of Posture collectors Is it necessary to mention how the posture collectors get their name in this I-D? Also, I can't tell what the difference is between static and dynamic by the examples given.=20 In addition, the name is primarily used by the NEA server (with PBC acting as intermediary). Section 5.1.1.2 Posture Broker Client Add that the PBC has responsibility for receiving and possibly asserting the overall endpoint compliance result. Section 5.1.1.3 Posture Transport Client Is the reason for several PTC in an NEA client, the need to deal with different PT protocols? Need to clarify. Section 5.1.2 NEA Server I would leave out the sentence that says the PBS and PV may not be co-located since it is not in scope.=20 Section 5.1.2.1 Posture Validator 3rd para p 16: Similar comment to one above. Section 5.1.2.2 Posture Broker Server Add to list of responsibilitiies to send overall compliance result to PBC. Section 5.1.2.3 Posture Transport Server Analogous comment to 5.1.1.3. Section 5.2.2. PB protocol Rather than introducing session terminology in this draft, can we just say that PB protocol may need to establish context during an assessment of a particular NEA client? Section 5.2.3. PT protocol First para, 2nd-4th sentences: I think this requirement should be removed from here and is best stated as part of the overall NEA protocol requirements in Section 7. See related comments in that section. Section 5.3 The PB protocol supports receiving and possibly asserting the overall posture result attribute as well? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jun 20 12:00:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12c1-0004Y1-Sl; Wed, 20 Jun 2007 12:00:53 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I12c0-0004VH-SK for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:00:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12c0-0004V4-HD for nea@ietf.org; Wed, 20 Jun 2007 12:00:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I12c0-0005vm-8j for nea@ietf.org; Wed, 20 Jun 2007 12:00:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2007 12:00:52 -0400 X-IronPort-AV: i="4.16,443,1175486400"; d="scan'208"; a="63259066:sNHT46550016" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5KG0pmQ027909 for ; Wed, 20 Jun 2007 12:00:51 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5KG0g63020701 for ; Wed, 20 Jun 2007 16:00:51 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 12:00:47 -0400 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 Date: Wed, 20 Jun 2007 12:00:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Section 6 - Use Cases Thread-Index: AcezVCoWWlxx3BguSnOAhm4dT8Ll9Q== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 20 Jun 2007 16:00:47.0683 (UTC) FILETIME=[2A9BD930:01C7B354] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1212; t=1182355251; x=1183219251; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20Comments=20on=20Section=206=20-=20Use=20Cases |Sender:=20 |To:=20; bh=lFzA580JXbDBzXpNFm8gQXD6wHvtDDhR5R1/v9hGrOE=; b=RxFxojajgclEhBW6aX/P6TmlSbOkbrq/Jb5RS4y8PQHcWMZ7OyY/NzVNO1gc32nwNuP8PQ0r 0qmOsdT4M0Sf+zH33Jj2WGlwxzE3avrHkUTFG+LflRK7cnpisBq6Dfzk; Authentication-Results: rtp-dkim-1; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Nea] Comments on Section 6 - Use Cases 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 General comment: I think "less is more" in this section particularly. There is detail in the examples that does not impact the protocol requirements. There is also a lot of duplication.=20 I would suggest trying to collapse this into a single general flow. The flow can be generalized to accommodate either the client or the server establishing the PT connection (e.g. the first bullet in the flow could be "the PT client or PT server establish a PT connection), and the presence or lack of assertion attributes (i.e. the flow could indicate that posture and/or assertion attributes can be returned). Examples of events that might trigger a PT connection being established from either client or server end can be summarized upfront as they are to a large extent already. Examples of conditions under which different types of attributes might be used can also be summarized.=20 Other suggestions/edits for the flow: - It should be indicated that the posture request/response exchange could be a multi-step process - Ensure that flow is not specific to any choice of PT e.g. PTC in diagram should not be shown as requesting access. This is not the role of the PTC component as defined. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jun 20 12:01:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12cg-00059p-88; Wed, 20 Jun 2007 12:01:34 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I12ce-00057l-GJ for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:01:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12ce-00057d-6d for nea@ietf.org; Wed, 20 Jun 2007 12:01:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I12cc-0006Jw-Up for nea@ietf.org; Wed, 20 Jun 2007 12:01:32 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Jun 2007 12:01:21 -0400 X-IronPort-AV: i="4.16,443,1175486400"; d="scan'208"; a="124133423:sNHT1491935152" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5KG1KpN012440 for ; Wed, 20 Jun 2007 12:01:20 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5KG1G5j020911 for ; Wed, 20 Jun 2007 16:01:20 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 12:01:19 -0400 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 Date: Wed, 20 Jun 2007 12:01:18 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Section 7 - Requirements Thread-Index: AcezVD0hAOrpVv7FTlCjPxbwbkBWyQ== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 20 Jun 2007 16:01:19.0597 (UTC) FILETIME=[3DA189D0:01C7B354] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1278; t=1182355280; x=1183219280; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20Comments=20on=20Section=207=20-=20Requirements |Sender:=20 |To:=20; bh=KIy8x17WtSC9thWbwPGMbIICZQm9o9n0ieMmqza2scM=; b=BsoycwbAFcmL5hUaYoGtsowSHkIN/3qp+e95ZVaRX2dPrITHTePxicLtX69lPW6AB6UIzxvT 5MA5ec3nDiZ8IqvVnH08/6bOAhrkyU/6DON13EeJsoVn8UDKJY8q8pYM; Authentication-Results: rtp-dkim-2; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Nea] Comments on Section 7 - Requirements 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 C-2: This requirement is unclear as currently worded and seems to assume use of a particular access control technology. Suggest rewording to "NEA protocols MUST allow posture assessment to occur prior to an endpoint gaining normal network access and after such network access has been achieved." Omit the next couple of sentences. C-5: Either remove examples or make more inclusive e.g SSL, TLS PA-4: The term session is overloaded and hence confusing. Do you mean in a single PT connection (where the definition of connection is defined by the PT protocol itself)? PB-1: What result and remediation attributes are being referred to here? The overall posture result? Best to generalise and say carries PA attributes and attributes specific to PB layer. PB-3: Since the term session is best defined by the protocol definition itself, could the reqt be worded as follows:? The PB protocol MUST be able to correlate messages in a multi-message dialog between a NEA client and server. This allows each party to send multiple messages before the dialog is complete. =20 PT-1: us -> use PT-7, PT-8: Not clear what is meant by the term restricted session. I think these have been covered in the general protocol requirements so can be omitted. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jun 20 12:04:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12fF-0005Xu-3m; Wed, 20 Jun 2007 12:04:13 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I12fE-0005Xo-36 for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12fD-0005Xg-Po for nea@ietf.org; Wed, 20 Jun 2007 12:04:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I12fD-0007b8-GA for nea@ietf.org; Wed, 20 Jun 2007 12:04:11 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2007 12:04:11 -0400 X-IronPort-AV: i="4.16,443,1175486400"; d="scan'208"; a="63259466:sNHT50498928" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5KG4BHe014043 for ; Wed, 20 Jun 2007 12:04:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5KG3h6J021706 for ; Wed, 20 Jun 2007 16:04:11 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 12:03:47 -0400 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 Date: Wed, 20 Jun 2007 12:03:47 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Section 2 - Terminology Thread-Index: AcezVJWeScQJ3gL6Q8W7xa5miy6RTQ== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 20 Jun 2007 16:03:47.0956 (UTC) FILETIME=[960F5340:01C7B354] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2695; t=1182355451; x=1183219451; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20Comments=20on=20Section=202=20-=20Terminology |Sender:=20 |To:=20; bh=BHpA4tAWTvcD04hWobKfAyK1QpmfYmUIw91ehez26WI=; b=MsVvHNwDOHyUnzEsCyweA0fF8kM0LVoK8LRZpcQiI4Fhv9JeueXiXsXum0nU0x12f7E5Y9B2 Ov+OOF+LYwBDGNRlMVWghOXgtDA3OEoYHX46eQkEj7ISOTDXFdyj7+wF; Authentication-Results: rtp-dkim-2; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Nea] Comments on Section 2 - Terminology 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 General Comment: I find those terms that are defined very generically e.g. component, session, deployer somewhat confusing, esp. where they are used to mean different things in different contexts. Have made some suggestions below. Re Deployer: I think you use this only in the context of "a deployer of NEA technology" in which case I think you can say this in the text without defining a special term. Re Session: This term is used in different contexts in the draft. I think this term is best defined in the protocol document itself, rather than a requirements doc since the definition is protocol-specific. In the context of PB layer, rather than use the term session it could be said to maintain context. In the context of PT layer, we could use the term connection (where the precise definition would be specific to the choice of PT), etc. Re Dialog: Is this really needed? It seems like if we replaced "message dialog" with "message exchange" in the text it would be clear without defining a special term. If we retain it, we should specify it more precisely that it is between NEA client and server and the context e.g. within a specific instantiation of PT. Re Owner: May need to loosen this definition a bit to take into account the fact that certain enterprise may lease (rather than own) their assets. Also, a small enterprise may hire a 3rd-party to manage their assets. Re Component: I think this definition can be omitted without loss of clarity. It is fine to use this term in the context of the reference model to refer to posture collector, validator etc. I think it has a well understood meaning in this context. Where it is used to refer to the local operating domain from which posture is collected, it is not clear what is meant by "endpoint components".=20 The definitions of assessment, attribute, message, etc could be easily modified to not include the term component. For example: Assessment could be modified as follows: The process of collecting posture from NEA client on the endpoint such that the NEA server can evaluate the posture against compliance policy.=20 Attribute could be modified to be: Data element including any requisite meta-data describing an observed ... property of the endpoint that is relevant to a compliance decision, ... Message: Self-contained unit of communication in the PA layer of the NEA protocol between a Posture Collector in the NEA client and Posture Validator in the NEA server. Posture Attribute: Describes specific characteristic of endpoint posture e.g. a Posture Attribute might describe the version of an application installed on the system. Thanks Susan _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jun 20 16:02:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16Nf-0007jA-R7; Wed, 20 Jun 2007 16:02:19 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I16Ne-0007j5-7N for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 16:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16Nd-0007ix-UA for nea@ietf.org; Wed, 20 Jun 2007 16:02:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16Nb-0002LS-Gb for nea@ietf.org; Wed, 20 Jun 2007 16:02:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2007 16:02:15 -0400 X-IronPort-AV: i="4.16,444,1175486400"; d="scan'208"; a="63289374:sNHT647415908" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5KK2Bth017879 for ; Wed, 20 Jun 2007 16:02:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KK2BBg011835 for ; Wed, 20 Jun 2007 20:02:11 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 16:01:29 -0400 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 Date: Wed, 20 Jun 2007 16:01:28 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Section 1 - Introduction Thread-Index: AcezdcoXx5PmfCOKR5K/g48ZhLpTMg== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 20 Jun 2007 20:01:29.0625 (UTC) FILETIME=[CAAD5090:01C7B375] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3201; t=1182369734; x=1183233734; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20Comments=20on=20Section=201=20-=20Introduction |Sender:=20 |To:=20; bh=SSj/H4YPgIIr4weaEWNxon+hPH8LCAy1Xz09dXKSA9Q=; b=qAKSyf2q7ThAqcXoZmwFla/8tLW3ZxzJbgR5I4SsR2wxeDdxafK/V6dubBIz8DxUGneuwytt WLrUbsu10RmReZe5h4WqVCOK4xd+6FMgbpKcfYnbOEmAjxzjAP9458PT; Authentication-Results: rtp-dkim-2; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Nea] Comments on Section 1 - Introduction 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 Below are review comments of Section 1 of the -02 reqts I-D. Thanks Susan --------------------- Section 1. Introduction First para, pg 3: I suggest removing the first paragraph. I don't believe the content in this paragraph is necessary, and could be problematic. For example, the first paragraph can be read to imply that NEA will protect the network from infected hosts (even though I don't think you intend it this way). Second para, pg 3:=20 Given removal of the first paragraph, the paragraph can be modified as follows. This is a combination of the current text in the I-D and text in the charter.=20 NEA protocols are used to proactively assess the state of systems joining or present on the network to determine their status relative to network compliance policies. For example, if a system is determined to be out of compliance because it is lacking proper defensive mechanisms such as firewalls, anti-virus software or the absence of critical security patches, the NEA protocols provide a mechanism to detect this fact and indicate appropriate remediation actions to be taken. The intent of NEA is to facilitate corrective actions to address known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network. The network may thus continue to be exposed to such threats as well as the range of other threats not addressed by maintaining endpoint compliance. Third para, pg 4: Re the last 2 sentences starting "Some systems may be incapable ...". I don't think this document needs to be saying anything about the policies used for endpoints that do not run the client software. Either say such endpoints are out of scope of the document, or don't mention them at all. I prefer the latter. Fourth para, pg 4: I would suggest replacing this paragraph with this slightly modified version from the charter to make the various deployment options clearer. An organization may make a range of network access policy decisions based on the compliance of an endpoint. Supported deployment scenarios include, but are not limited to, providing normal access regardless of compliance result along with any recommendations for remediation ("advisory mode"), as well as providing restricted access sufficient for remediation purposes and any essential services until an endpoint is in compliance ("mandatory mode"). Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. Fifth para, pg 4: I think the industry architectures should be omitted. These are not relevant to this document which needs to stand on its own. Last para, pg 4: This paragraph could be made more precise. Something like: The priority of the NEA working group is to develop standard protocols that can be used to communicate compliance information between a NEA client and a NEA server. This document describes terminology, applicability, problem statement, reference model, and use cases. It then identifies requirements for the protocols used to communicate between a NEA client and NEA server. =20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jun 20 16:26:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16lL-00052Z-Pl; Wed, 20 Jun 2007 16:26:47 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I16lJ-0004t9-UM for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 16:26:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16lJ-0004t1-Kn for nea@ietf.org; Wed, 20 Jun 2007 16:26:45 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16lJ-0007cY-BL for nea@ietf.org; Wed, 20 Jun 2007 16:26:45 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 20 Jun 2007 13:26:45 -0700 X-IronPort-AV: i="4.16,444,1175497200"; d="scan'208"; a="22320692:sNHT36441336" 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 Date: Wed, 20 Jun 2007 16:26:51 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Substantive comments Thread-Index: AcezeVXLYnOS1kwmTYSpXFuoAujCwg== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Nea] Substantive 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: , Errors-To: nea-bounces@ietf.org I have a lot of non-substantive comments (typos and such) on the latest NEA requirements draft so I have divided my comments into two emails: one with substantive comments (this one) and another that I'll send in a minute with only minor comments. Thanks, Steve ------------- Section 5.1.1.1 says "Each Posture Collector will be associated with an identifier..." Depending on how things work, there may be more than one identifier per Posture Collector so I think we should say "...associated with one or more identifiers...". This comment applies to other parts of the document as well, such as section 5.1.2.1. Section 5.1.2.1 talks about a Posture Validator's "corresponding Posture Collector". I don't think there will always be a one-to-one mapping from one Posture Collector to one Posture Validator. One Posture Collector may be able to handle Anti-Virus and Personal Firewall messages while another may only be able to handle Anti-Virus. The same holds true for Posture Validators. This comment applies to other parts of the document as well, like section 5.2.1. In section 5.2.2, PB should be able to carry non-PA messages other than the global assessment decision. For example, it may be useful to have PB carry information about the user's preferred language. That way, this information can be made available to all Posture Validators so they can send any messages in the preferred language. The first paragraph of section 5.3 says "The NEA WG will define a common (standard) set of attributes that are expected to be supported by all Posture Collectors." I don't think we want to require all Posture Collectors to support all of the standard attributes, do we? In section 7.1, requirement C-4 should require that NEA protocols include protection against attacks by endpoints. In section 7.2, the first sentence says that PA defines a transport. I don't think so. PB and PT do that. PA is more like a format. This comment also applies to other parts of the document, like section 5.2.1. Requirement PA-1 says "The PA protocol MUST support transport of the required (standard) attributes defined in the data model." But there's no data model any more, just standard and vendor-specific attributes. I think we should have PA-1 require support for the standard attributes and PA-2 can cover the vendor-specific attributes. Requirement PB-1 lists some specific messages and says the PB protocol must be capable of carrying those. I think it should instead just say that the PB protocol muse be capable of carrying all PA msgs and also standard & vendor-specific non-PA messages. Requirement PB-2 should not talk about peer Posture Collectors and Posture Validators. Instead, it should explicitly support the idea that one Posture Collector or Posture Validator may map to several of the other. Requirements PT-7 and PT-8 are already covered better by requirements C-2 and C-3. We shouldn't have PT requirements for these since this implies that all PT protocols MUST support these use cases. We should allow some PT protocols to specialize in one use case or another. Section 8.3.4 refers to "carrier protocols". Those are in PT now so we shouldn't be referring to them separately. In section 9.1, I think the phrase "explicitly not" should be "not explicitly". At least, I hope so! _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jun 20 16:27:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16mL-0007Of-PO; Wed, 20 Jun 2007 16:27:49 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I16mK-0007OF-Ay for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 16:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16mK-0007O7-1G for nea@ietf.org; Wed, 20 Jun 2007 16:27:48 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16mJ-0007rR-3G for nea@ietf.org; Wed, 20 Jun 2007 16:27:48 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 20 Jun 2007 13:27:46 -0700 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 Date: Wed, 20 Jun 2007 16:27:52 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minor comments Thread-Index: AcezeXnyp3DQBpb+Sdmr2yw6Ngos0Q== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Subject: [Nea] Minor 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: , Errors-To: nea-bounces@ietf.org Here are my more minor comments, probably not worthy of discussion. But speak up if you have any concerns. Thanks, Steve ------------ On page 4, "its configuration" should be "their configuration" because "systems" is plural. Halfway down page 4 in the sentence that begins with the word "Architectures", I think we should say the existing architectures "don't offer adequate interoperability" not that they "don't offer interoperability". The TCG TNC architecture is supported by a lot of products and it offers lots of interoperability among those products but it does not offer full interoperability with Cisco NAC products, for example. I'm not suggesting we add any details here, just add the word "adequate". At the end of that paragraph, I think we should delete the last sentence ("These architectures ..."). Most of these architectures actually use standards like RADIUS and EAP. The problem is that the NAC architectures use them in different, incompatible ways. On page 5 in the definition of "Assertion Attributes", I suggest that we simplify the first part of the definition by changing the text from "Attributes sharing the property that they [...]" to "Attributes that [...]". This is much simpler and it says basically the same thing. In the next definition on page 5, I think there's a word missing before the word "status". The current text says "Data element [...] describing an observed, expected or status of a component property." Maybe the missing word is "requested"? On page 6 in the definition of the term "endpoint", "cell phones" should be plural (to match the other kinds of devices) and "with an IP address" should be "that may have an IP address" (since the devices may not have an IP address at the time they are assessed). In the definition of the term "Message", the phrase "a component" should be changed to "one or more components" since a single PA message might include information about AV and Personal Firewall or about the patch level of OS and application components. In the definition of the term "Owner", the words "possessor on an asset" should be changed to "possessor of an asset". The change here is to change the word "on" to "of". This is a typo. On page 7 in the definition of the term "Session", I suggest that the word "subscribed" be removed from the definition. That term presupposes a particular model for Posture Collector ID management. In the definition of the term "User", I suggest that the phrase "to perform her job" be changed to "for business purposes". This expands the idea of what activities would be permissible and avoids the problem of deciding on a gender for the pronoun. In the first paragraph of section 3, I suggested that we add the word "the" before the phrase "technologies being standardized". This will clarify that section 3 covers only the technologies being standardized in the NEA WG not any other technologies being standardized. In the first paragraph of section 3.1, I suggest that we change the phrase "local interfaces between NEA Reference Model components" to "interfaces between other NEA Reference Model components" because the interfaces in question (the ones we're not standardizing) may not be local (constrained to one system). For instance, a Posture Validator may be located on a different machine from the Posture Broker Server. The change here is to remove the word "local" and insert the word "other". Later in that paragraph, I suggest that we change the words "provided to provide context" to "not normative and provided only to provide context". I think this will clarify that any discussion pertaining to other interfaces is not normative. In the second paragraph of section 4, I suggest that we replace the reference to "guest machines" with a reference to "contractors' machines". It's more likely that a corporation would want to assess the posture of contractors' machines than guest machines. Often, guest machines are simply given Internet access while contractors' machines have to get access to more sensitive resources and networks. Later in that same paragraph, I suggest changing "quarantined where needed" to "quarantined when needed". I think the intent of these last few words is to emphasize that assessment, remediation, and quarantine can be used when and as appropriate. The current text might lead the reader to focus instead on quarantining the endpoint in the proper location. The first word in the next sentence should be "endpoints" not "endpoint" since the verb is "are". In the following paragraph (the first full paragraph on page 10), "the non-compliant endpoint" should be "a non-compliant endpoint". I believe the reference here is supposed to be to an indeterminate endpoint, not a specific one. In the last sentence of that paragraph, the words "on the network" should be deleted. They are unnecessary and confusing. In the last paragraph of section 4, the word "by" should be removed from the last sentence and replaced with a comma. Otherwise, this sentence can easily be understood to mean that the endpoints in question are employing service triggered assessment to access applications. Instead, the enterprise is using service triggered assessment to protect applications. The endpoint is simply trying to access those applications. In the first paragraph of section 5, please remove the comma between "thin" and "message wrapper". It's unnecessary and confusing. In the following paragraph (immediately after Figure 1), change "allow" to "allows" since "information" is singular. At the end of this paragraph, change "part of" to "in". The former is not grammatical. At the end of this sentence, I suggest that we change "the Posture Transport" to "PT" or (less preferred) change it to "the Posture Transport Protocol". The current phrase could be mistaken as a reference to the Posture Transport Client or Posture Transport Server. In the bulleted list at the start of section 5.1.1, change "Posture Collector" to "Posture Collectors". There will often be several Posture Collectors. I think it is misleading to just mention one. In the paragraph after the bulleted list, change the word "system" to "endpoint". That's the term we've been using throughout for the device that hosts the NEA Client. In the next paragraph, remove the word "is" from the first sentence. It's extraneous. Later in that paragraph, change "multiple domain posture" to "posture for multiple domains". I'm pretty sure the new phrase will be clearer for new readers (assuming I understand what you are trying to convey). In the first sentence of section 5.1.1.1, change "(Remediation Attributes)" to "in Remediation Attributes". This is more consistent with the reference to Result Attributes that appears earlier in the sentence. At the end of this paragraph (on page 13), spell out the acronym "IDS". This is the first time that acronym appears in the document (although not the last). In the second paragraph of section 5.1.1.1 (on page 13), remove the word "the" before the word "specified". See my earlier substantive comment on having more than one identifier per Posture Collector. On page 13, in the second sub-bullet of the second bullet in the bulleted list remove the word "a" from the phrase "applicability of a recently issued attributes". In the first bullet on page 15, change the comma into a period and capitalize the first letter of the following word ("the"). The responsibility being delegated is "initiating and maintaining the communication channel to the NEA Server". The next part of the text is just an explanation. In the bulleted list at the start of section 5.1.2, change "Posture Validator" to "Posture Validators". There will often be several Posture Validators. I think it is misleading to just mention one. In the first paragraph of section 5.1.2.1 (on page 15), change the word "pass" to "send". Getting a request from a Posture Validator to a Posture Collector requires a long route. I think the word "pass" makes it sound like a short (maybe local) trip. In the bulleted list on page 16, the words "Result" and "Remediation Instructions" are capitalized several times. I think that's left over from the old and now abandoned convention of capitalizing words that are listed in the Terminology section. They should be lower case. In section 5.1.2.2, the first occurrence of "Posture Broker Client" should be "Posture Broker Server". I suggest placing the "e.g." in parentheses. The current punctuation (using one comma) isn't right. I also suggest changing "in" to "into", changing "returns" to "sends" (because this is not a local operation), and adding the phrase "via the Posture Transport Protocol" at the end of the sentence. That should clarify things. Later in that paragraph, I suggest removing the parentheses around the "s" in "(PA messages(s))". These parentheses are not necessary since the phrase "Posture Collector responses" is already plural. Nested parentheses are somewhat awkward, anyway. In the second paragraph of section 5.1.2.2, the comma after the phrase "various Posture Validators" should be a period and the following word ("this") should be capitalized. These are really two separate sentences. The second bullet in the list at the end of sectin 5.1.2.2 should probably just say "from and to the relevant Posture Validators" instead of "between the NEA Client and the relevant Posture Validators". In the third bullet, the global assessment decision is also based on policy. You might want to mention that. In the second sentence of section 5.1.2.3, I think "more than one Posture Transport Servers" should be "more than one Posture Transport Server". In section 5.2.2, I suggest that you delete the word "requested" from the first sentence. Even Posture Collectors that have not been explicitly "requested" should be able to send PA messages. This is needed for endpoint triggered reassessment. In section 5.3.2, I suggest that the word "describe" be changed to "explain". As described in the Terminology section, remediation attributes generally provide instructions for how remediation should be done. So the term "explain" is more accurate than "describe". In the first paragraph of section 6, I suggest adding "or the only use cases" after "the only approach to addressing the use case". This will clarify that there may be other use cases. At the end of this paragraph, I find this clause somewhat awkward: "how the flows might occur and require support from the NEA protocols". I suggest that it be reworded along these lines: "how the flows might occur and what support they might require from the NEA protocols". In the second paragraph of section 6, "their" should be "its". In the first bullet on page 21 (section 6), the word "a" is missing before the phrase "request to use a service". Also, I suggest that the start of that sentence be changed from "This might" to "This evaluation might". Otherwise, it's not clear what "this" refers to. In the second bullet on page 21, "This could" should probably be "This evaluation could". Otherwise, it's not clear what "this" refers to. I will not provide minor comments on the subsections of section 6 at this time since Susan has suggested substantial changes to this part of the document. In section 7.1, change "NEA conceptual architecture" to "the NEA reference model". The term "conceptual architecture" has been replaced with the term "reference model" everywhere else in the document. In requirement C-8, "attributes messages" should be "attribute messages". In requirement C-10, "amount information" should be "amount of information". At the end of requirement PA-4, I suggest that we change "information about additional component" to "additional information as needed". The ability to request Posutre and Assertion Attributes more than once isn't just needed to request information about additional components. It can also be used to request additional information about components previously interrogated. For instance, the first request might ask which version of an application is being used. The second one might ask about settings specific to that application version. In requirement PA-5, "the Posture Validator" should be "a Posture Validator" since no specifi Posture Validator is being referred to. In requirement PA-7, I think "provide" would be better wording than "support". The PA protocol needs to more than supporting those protections. It needs to actually provide the protections. Later in the sentence, the comma after "attributes" should be removed. Otherwise it's not clear that the word "sent" is modifying the attributes and not the protections (authentication, etc.) The first paragraph of section 7.3 describes how the PB protocol allows attributes to be sent from Posture Collectors to Posture Validators. That's good but it should also mention that the PB protocol supports transmission in the opposite direction as well. In the third sentence of requirement PB-4, "allow" should be "allows" and "be implemented" should be "to be implemented". In requirement PT-1, "us" should be "use". Requirement PT-2 only applies in certain specific environments (like EAP) so I suggest that we add at the end of this requirement these words: ", if this is valuable for the intended lower layer protocols". In requirement PT-5, the second sentence is a bit confusing. I suggest that we revise the section that currently says "perform fragmentation, reassembly, and detect duplicates and reorder" to say "perform fragmentation and reassembly, detect duplicates, and reorder". This revision is intended to reflect the fact that fragmentation and reassembly are one logical unit, as are duplicate detection and reordering to provide in-sequence delivery. In the second paragraph of 8.1, I suggest changing "these parties" to "the components in the NEA system" or something similar. This should help clarify which parties you're referring to. If you want to be even more clear, you could add a parenthetical list: NEA Client, NEA Server, and network. In the first paragraph of section 8.1.1, the clause "if such mechanisms do come into existence" implies that such mechanisms do not now exist. In fact, mechanisms for detecting lying endpoints already exist: the TPM and PTS. I suggest that this clause be changed to "if such mechanisms are employed in a particular deployment". The first sentence of the third paragraph of section 8.1.1 is a bit confusing. I suggest changing the word "it" in that sentence to "this trust" to remove ambiguity about what "it" refers to. I also think we should not require a policy to be established. A user or owner action should be sufficient to authorize trust. In light of this, I suggest changing "the user or owner defined policy" to "a user or owner policy or action". Later in that paragraph, I suggest changing "the NEA assessment" to just "NEA assessment" since there's no one specific assessment referred to here. This is a general statement. In the second paragraph of section 8.1.2, I suggest we change "DOS" to "attempt to disrupt". There are lots of ways to disrupt communications other than dropping messages or mounting a denial of service attack. The intermediaries could inject bad packets or replay packets, for instance. This would not be a true DOS attack since it would only affect one session. In the third paragraph of section 8.1.2, we should add commas to the list, changing it to "remediation, isolation, and access controls". Otherwise, it's not immediately clear that it is a list. In the first paragraph of section 8.1.3, the word "remote" should not be in parentheses. Otherwise, it is implied that this word is not essential to understanding the meaning of the sentence. That's not true. This sentence is specifically addressing the matter of remote Posture Validators. At least, that's my understanding. Later in the paragraph, the words "are protected" should be changed to "must be protected". We should invoke a sense of urgency here not complacency that such protection is already provided. In the third paragraph of section 8.1.3, I suggest that "each of the NEA Server components" be changed to "some of the NEA Server components". For this example, it's not necessary for all of the NEA Server components to reside on different systems, just some of them. In the second paragraph of section 8.3.1, "either party" should be "both parties". With mutual authentication, the MITM must convince both parties that it is legitimate (unless the MITM can convince one of the parties to disclose its authentication secrets to him, which should not be possible). Later in that paragraph, "prevent" should be "prevents". At the end of the first paragraph of section 8.3.2, I suggest changing the example attack to one where the attacker sends bad remediation instructions, causing previously compliant systems to become vulnerable or infected. This is worse than simply hiding non-compliance and I think we should highlight the worst case. At the end of the second paragraph of section 8.3.2, the word "existed" should be changed to "is located". We're not concerned with where the Posture Validator might have existed at some time in the past but where it is located at this time. Earlier in that sentence, I think we need a comma before "extending" to clarify that "extending" modifies the inclusion of the requirement not the attributes. In the first sentence of section 8.3.3, I think we need a comma before "recording". Otherwise, readers may think that the network is recording. The last sentence of this paragraph does not provide much clarification or guidance. Therefore, I suggest replacing that sentence with this one: "For this reason, the PT protocol is required to provide confidentiality and replay prevention." In the first sentence of the third paragraph of section 9, I think it's important to clarify who must establish "a clear expectation of disclosure/compliance". Therefore, I suggest adding the clause "the endpoint owner has established" before that phrase and removing the words "has been established" after the phrase. In the fourth paragraph of section 9.1, I think "of" should be "on" in the phrase that currently reads "policies of the attributes". I don't think you usually have policies of something. Instead, I think you usually have policies on something. At the end of this paragraph, the word "to" before the word "whether" should be removed. It's redundant. In the first sentence of the next paragraph, "be" should change to "is" to be consistent with the verb "articulates". In the bulleted list later on that page, the punctuation at the end of each bullet should be removed. There's no need for it and it's distracting, especially with such short bullets. In the References section, are [IPSEC] and [TLS] really normative? I think they're just mentioned as examples. Actually, I think this is also true of [EAP], [HMAC], and [RADIUS] also. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jun 20 16:49:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I177V-0004HC-4l; Wed, 20 Jun 2007 16:49:41 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I177T-0004H7-Ce for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 16:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I177T-0004Gz-30 for nea@ietf.org; Wed, 20 Jun 2007 16:49:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I177R-0004in-QA for nea@ietf.org; Wed, 20 Jun 2007 16:49:39 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Jun 2007 16:49:32 -0400 X-IronPort-AV: i="4.16,444,1175486400"; d="scan'208"; a="124169959:sNHT1005199008" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5KKnVlL009510 for ; Wed, 20 Jun 2007 16:49:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KKnNC4025335 for ; Wed, 20 Jun 2007 20:49:31 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 16:49:29 -0400 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 Date: Wed, 20 Jun 2007 16:49:28 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Section 8,9: Security/Privacy Considerations Thread-Index: AcezfH7EiyMqlYaCRJafzcUYwe8x7g== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 20 Jun 2007 20:49:29.0413 (UTC) FILETIME=[7F2A1750:01C7B37C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2856; t=1182372571; x=1183236571; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20Comments=20on=20Section=208, 9=3A=20Security/Privacy=20Conside rations |Sender:=20 |To:=20; bh=GGekBCl2xO4ogL6XCIPXB5+rvOYz/MOjkf7YOU5y3wg=; b=0NrHKaaTQWunamBR7D04s3c/GE42/fFVHUb2uvcbiXELs36twnBfyuT2Tk7IdDY6Je5ta+dN BaRH1yCsLgMoVyk24tIHqQPiMRo/T2lPTthWwLjrm2Cau5NEmE7F4nr6; Authentication-Results: rtp-dkim-2; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Nea] Comments on Section 8,9: Security/Privacy Considerations 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 Section 8. Security Considerations General comment: I think there needs to be a clear and explicit statement upfront of what NEA does and what it does not do in terms of security. This was an important point made in the charter discussions. For example, something along the lines of the following: "the intent of NEA is to facilitate corrective actions before a host is exposed to potential attack. Endpoints that are deemed compliant may still be vulnerable to threats. Hence, the network may still be exposed to such threats as well as any others not addressed by maintaining endpoint compliance". Section 8.1 Trust 1st para, 2nd sentence p37: Suggest rewording to: "Therefore, there is an implied distrusting of endpoints until there is reason to believe (based on posture information) that they are *protected from threats addressed by the compliance policy*." Section 8.1.2 Network Communications 3rd para beginning "Second", p39:=20 omit "given to them by the NEA Server" since the role of NEA server as defined in this document is not as a network authorization server. Replace with 'when NEA is being deployed in a mode such that an endpoint has restricted access until the endpoint is deemed to be in compliance.' or some such. 4th para beginning "Third", p39:=20 Suggest removing the example in this paragraph. I think the paragraph is clear on its own and the draft up till this point has not mentioned protocol choices so this appears to come out of the blue.=20 Section 8.1.3 NEA Server Components General comment: I would avoid the use of the term "enforce" in the context of the NEA server since it is often used within the context of network access control. While the NEA server may provide input into a network authorization decision, the NEA server itself is not defined in this draft to be a network authorization server. 1st sentence, 1st para, p40: Use word "apply" instead of "enforce". 2nd para, p 40: Omit "or enforcements". 3rd para, p40: Omit this paragraph since not in scope. Section 8.2 Protection Mechanisms at Multiple Layer 3rd para, p41: "enforcing" -> "providing" Section 9: Privacy Considerations 3rd para: The overall point here is valid. However, it would be good to generalize this text and the term "owner" a bit to be cognizant of the fact that corporate assets are not necessarily purchased and owned - they could be leased, for example. Also, assets are not necessarily managed by enterprise itself, but could be an organization they hire to do so. Using the term "managed" may be better than "owned". =20 Section 9.2: Is the intent that this subsection be updated based on discussions at the last IETF? It is not clear to me we need this section. I don't think this draft needs to get into how the privacy policy is distributed. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jun 20 16:57:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I17F3-0006qy-15; Wed, 20 Jun 2007 16:57:29 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I17F2-0006q6-KV for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 16:57:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I17F2-0006py-B1 for nea@ietf.org; Wed, 20 Jun 2007 16:57:28 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I17F2-00079e-0H for nea@ietf.org; Wed, 20 Jun 2007 16:57:28 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EKsf4VRTmSXkZVcZgTs51z3/H5uOoDyyhh3Q/+sBzuQf8xbpRwHebSzUgpuMlm/B; h=Received:Message-ID:From:To: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 [64.125.79.23] (helo=gw) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I17F1-0007mV-IX; Wed, 20 Jun 2007 16:57:27 -0400 Message-ID: <00b401c7b37d$9c24a680$174f7d40@home.glassey.com> From: "todd glassey" To: "Susan Thomson \(sethomso\)" , References: Subject: Re: [Nea] Comments on Section 8,9: Security/Privacy Considerations Date: Wed, 20 Jun 2007 13:57:25 -0700 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79a300cb38bab4b7591c25029ffafd874c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 ----- Original Message ----- From: "Susan Thomson (sethomso)" To: Sent: Wednesday, June 20, 2007 1:49 PM Subject: [Nea] Comments on Section 8,9: Security/Privacy Considerations Section 8. Security Considerations General comment: I think there needs to be a clear and explicit statement upfront of what NEA does and what it does not do in terms of security. TSG: AMEN! This was an important point made in the charter discussions. For example, something along the lines of the following: "the intent of NEA is to facilitate corrective actions before a host is exposed to potential attack. TSG: WHAT LEVELS OF ATTACK - i.e. before DHCP assigns an address for it or? - see what I mean? there needs to be a statement of where NEA starts to be effective in its standards docs. Endpoints that are deemed compliant may still be vulnerable to threats. Hence, the network may still be exposed to such threats as well as any others not addressed by maintaining endpoint compliance". Section 8.1 Trust 1st para, 2nd sentence p37: Suggest rewording to: "Therefore, there is an implied distrusting of endpoints until there is reason to believe (based on posture information) that they are *protected from threats addressed by the compliance policy*." TSG: If you are enumerating COMPLIANCE POLICY - this has new meaning for many organizations and so it needs to be properly framed. Section 8.1.2 Network Communications 3rd para beginning "Second", p39: omit "given to them by the NEA Server" since the role of NEA server as defined in this document is not as a network authorization server. Replace with 'when NEA is being deployed in a mode such that an endpoint has restricted access until the endpoint is deemed to be in compliance.' or some such. 4th para beginning "Third", p39: Suggest removing the example in this paragraph. I think the paragraph is clear on its own and the draft up till this point has not mentioned protocol choices so this appears to come out of the blue. Section 8.1.3 NEA Server Components General comment: I would avoid the use of the term "enforce" in the context of the NEA server since it is often used within the context of network access control. While the NEA server may provide input into a network authorization decision, the NEA server itself is not defined in this draft to be a network authorization server. 1st sentence, 1st para, p40: Use word "apply" instead of "enforce". 2nd para, p 40: Omit "or enforcements". 3rd para, p40: Omit this paragraph since not in scope. Section 8.2 Protection Mechanisms at Multiple Layer 3rd para, p41: "enforcing" -> "providing" Section 9: Privacy Considerations 3rd para: The overall point here is valid. However, it would be good to generalize this text and the term "owner" a bit to be cognizant of the fact that corporate assets are not necessarily purchased and owned - they could be leased, for example. Also, assets are not necessarily managed by enterprise itself, but could be an organization they hire to do so. Using the term "managed" may be better than "owned". Section 9.2: Is the intent that this subsection be updated based on discussions at the last IETF? It is not clear to me we need this section. I don't think this draft needs to get into how the privacy policy is distributed. _______________________________________________ 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 Wed Jun 20 19:52:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I19yh-0003cm-QH; Wed, 20 Jun 2007 19:52:47 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I19yh-0003ch-Dp for nea-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 19:52:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I19yh-0003cZ-4J for nea@ietf.org; Wed, 20 Jun 2007 19:52:47 -0400 Received: from smtp3.stanford.edu ([171.67.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I19ye-0006Qf-KI for nea@ietf.org; Wed, 20 Jun 2007 19:52:47 -0400 Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0072F4BF8C for ; Wed, 20 Jun 2007 16:52:44 -0700 (PDT) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp3.stanford.edu (Postfix) with ESMTP id A8BBC4BF63 for ; Wed, 20 Jun 2007 16:52:43 -0700 (PDT) Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id l5KNqhr28425 for ; Wed, 20 Jun 2007 16:52:43 -0700 (PDT) Message-Id: <200706202352.l5KNqhr28425@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: nea@ietf.org From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jun 2007 16:52:43 -0700 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Subject: [Nea] fyi: soon - Free Rootkit (in hardware) with Every New Intel Machine X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nea@ietf.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Of possible interest: Intel Active Management Technology =5Baka Free Roo= tkit=20 (in hardware)=5D The security concerns highlighted by the malware worm scenario below seem= =20 apropos. A skim thru draft-ietf-nea-requirements-02 reveals that it does = not=20 seem to mention the possibility of NEA infrastructure being misappropriat= ed to=20 attack the network NEA clients en-masse. Also, does the couple'o orders of magnitude-in-sophistication jump being = taken=20 by (e.g.) Intel (as described below and in ref'd intel docs) potentially = affect (e.g. drive) the functionality breadth of NEA efforts? It isn't c= lear,=20 e.g. in skimming it=20 doesn't mention whether the beyond-TPM capabilities are based on any stan= dards=20 or not. =3DJeffH ------- Forwarded Messages From: pgut001=40cs.auckland.ac.nz (Peter Gutmann) To: cryptography=40metzdowd.com Subject: Free Rootkit with Every New Intel Machine Date: Mon, 28 May 2007 14:08:45 +1200 (Forwarded with permission from a NZ security mailing list, some portions= anonymised) - -- Snip -- =5B...=5D a register article saying Intel released its new platform Centr= ino Pro which includes Intel Active Management 2.5. An article with some more inf= o is here: http://www.newsfactor.com/news/Intel-Debuts-Fourth-Gen-Centrino-Tech/stor= y.xhtm l?story_id=3D0210025GSEV9 It got me interested, so I started taking a look around. Intel has some g= ood info here: http://softwarecommunity.intel.com/articles/eng/1032.htm And for all of you in the Web 2.0 generation with short attention spans f= or reading the doc, here is video that explains it all, I found myself getti= ng more and more concerned the further it went: http://softwarecommunity.intel.com/videos/home.aspx?fn=3D3D1066 Essentially, all new Intel machines (and a number of current Intel server= s) come with free hardware rootkit functionality, which is operational and accessible when the machine is powered off, and in the case of laptops, e= ven when they are unplugged and powered off. There is the mention of code signing, TLS and PKI magic to allay your sec= urity concerns however... There are a few new things with this that go beyond generic remote IP KVM= : - - NIC based TCP/IP filters configurable remotely - - Handy magic bypass for TCP/IP filters =5B1=5D - - Remote BIOS updates over the network - - Remote IDE redirection, as in boot off CDROM over the network - - Persistent storage even if you change hard disks - - It doesn't appear to have a method for disabling it (well, I can't fi= nd anything about it, seems crazy if there isn't) - - Built-in, on chip. I can understand a decent size company wanting IP-= KVM. But I don't want my personal laptop with IP-KVM. - - Authentication can be done on Kerberos. We're talking AD. - - Built in web interface on every machine (port 16994) - - handy well documented SDK for building whatever you need to interact = with this - - ... This is clearly an awesome management tool. Being able to update your antivirus while your machine is disconnected from the network is helpful.= Being able to id all your assets even though they are powered off is grea= t. My concerns are around doomsday scenarios like the below: Worm is released that gets a domain admin account, worm sets up floppy bo= oting across the network, floppy is boot-and-nuke =5B2=5D. Worm reboots every s= erver in the company and securely wipes them with single pass. Worm then updates b= ios on every machine to broken state, enables TCP/IP filters to prevent the N= IC from being used to talk to the OS ever again, then disables the AMT. Note, this is OS agnostic, will take out your OSX, Windows and Linux boxe= n. The hardware would probably be rendered useless, barring opening up the b= ox and flipping some jumpers or replacing something. A smart user noticing t= he reboot and noticing the disk was being wiped (assuming you didn't change = dban to say =22now making your computer faster by optimizing the cache flux capacitor=22) would have to unplug power and network to stop it, which is= harder if you're a laptop user with wireless. While parts of this are possible now, its just not nearly as powerful or ubiquitous. =5B1=5D TCP-over-Serial-over-LAN=20 http://softwarecommunity.intel.com/articles/eng/1222.htm =5B2=5D http://dban.sourceforge.net/ - -- Snip -- ------- Message 2 Date: Sun, 10 Jun 2007 12:42:12 +1000 From: =22James A. Donald=22 To: cryptography=40metzdowd.com Subject: Re: Free Rootkit with Every New Intel Machine Initially I did not believe it, thought it must be hype or hoax. Nope, it is a rootkit in hardware. http://www.intel.com/business/vpro/index.htm : : Isolate security tasks=E2=80=94in a separate : : environment that is hidden to the user : : : : =5B...=5D : : : : Perform hardware and software inventory on : : PCs=E2=80=94even if they don't have management : : applications installed or they are powered : : down, which increases reporting accuracy for : : licensing, maintenance contracts, and audits. : : : : Deploy software patches to PCs more : : efficiently=E2=80=94even if they are powered down or : : their OS is inoperable, without disrupting or : : slowing down the user's workflow. (The last paragraph means =22without the user knowing, and even if the=20 user is doing his best to stop you=22) ------- End of Forwarded Messages _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jun 21 19:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VeT-0007PJ-Bl; Thu, 21 Jun 2007 19:01:21 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I1VeS-0007Nh-1H for nea-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 19:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VeR-0007NZ-Nd for nea@ietf.org; Thu, 21 Jun 2007 19:01:19 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1VeR-00020H-1s for nea@ietf.org; Thu, 21 Jun 2007 19:01:19 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2007 16:01:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAISgekarR7PD/2dsb2JhbACPAQ X-IronPort-AV: i="4.16,449,1175497200"; d="scan'208"; a="5369399:sNHT17236146" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5LN1IhK022604; Thu, 21 Jun 2007 16:01:18 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LN1Ams014732; Thu, 21 Jun 2007 23:01:18 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 16:01:10 -0700 Received: from 171.69.75.129 ([171.69.75.129]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Jun 2007 23:00:49 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 21 Jun 2007 16:00:48 -0700 Subject: Re: [Nea] Substantive comments From: Kaushik Narayan To: Stephen Hanna , Message-ID: Thread-Topic: [Nea] Substantive comments Thread-Index: AcezeVXLYnOS1kwmTYSpXFuoAujCwgA3qvJM In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Jun 2007 23:01:10.0319 (UTC) FILETIME=[0EE26BF0:01C7B458] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7897; t=1182466878; x=1183330878; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20Kaushik=20Narayan=20 |Subject:=20Re=3A=20[Nea]=20Substantive=20comments |Sender:=20; bh=5vrQ+YUC/3djKxqPNBH4wFv3kes5CyilWtGD15f60C8=; b=B0BG+c7T3Hp2T4uALfSQU7ogWgHKJ+d8eJfhjyipms8peMnV17iIJYCdGTyaCSngL+JNnRdt r+5JBn38j3TG2p/8T+TrZw2qB76DROlLfI1gaDwS+CrHPF/2KTr9blhc; Authentication-Results: sj-dkim-3; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 1.6 (+) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 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 Steve, Thanks for your comments. Please find my response inline. On 6/20/07 1:26 PM, "Stephen Hanna" wrote: > I have a lot of non-substantive comments (typos and such) on > the latest NEA requirements draft so I have divided my comments > into two emails: one with substantive comments (this one) and > another that I'll send in a minute with only minor comments. > > Thanks, > > Steve > > ------------- > > Section 5.1.1.1 says "Each Posture Collector will be associated > with an identifier..." Depending on how things work, there may > be more than one identifier per Posture Collector so I think we > should say "...associated with one or more identifiers...". > This comment applies to other parts of the document as well, such as > section 5.1.2.1. Agreed. The text was meant to convey that there needs to be a mechanism to uniquely identify each posture collector. Will the following edit address your comment. "Each Posture Collector will be associated with one or more identifiers that will be used to uniquely identify the posture collector". > > Section 5.1.2.1 talks about a Posture Validator's "corresponding > Posture Collector". I don't think there will always be a one-to-one > mapping from one Posture Collector to one Posture Validator. One > Posture Collector may be able to handle Anti-Virus and Personal > Firewall messages while another may only be able to handle Anti-Virus. > The same holds true for Posture Validators. This comment applies > to other parts of the document as well, like section 5.2.1. > I agree that the text may be misleading but we certainly did not imply a 1-to-1 relationship. Will the following edit (and similar edits in other places) address the comment "A Posture Validator is a component that is responsible for handling Posture Attributes from corresponding Posture Collector(s). A Posture Validator can handle Posture Attributes from one or more Posture Collector(s) and vice-versa". > In section 5.2.2, PB should be able to carry non-PA messages other > than the global assessment decision. For example, it may be useful > to have PB carry information about the user's preferred language. > That way, this information can be made available to all Posture > Validators so they can send any messages in the preferred language. Agreed. We have discussed the possibility that the PB layer might require to handle additional attributes in the future and I agree that we should have text to indicate that possibility. > > The first paragraph of section 5.3 says "The NEA WG will define a > common (standard) set of attributes that are expected to be supported > by all Posture Collectors." I don't think we want to require all > Posture Collectors to support all of the standard attributes, do we? > I am not sure that we need all posture collectors to support all standard attributes infact I am not sure we are completely settled on how the standard posture attributes are handled. I think we should get rid of the second part of that sentence and just state that " The NEA WG will define a common (standard) set of attributes that will be present in all NEA deployments irrespective of vendor specific extensions" > In section 7.1, requirement C-4 should require that NEA protocols > include protection against attacks by endpoints. I am not sure about the comment. An endpoint is an intermediary in the network and hence covered by the existing text. Are you referring to attacks on the NEA client hosted on the endpoint from other endpoint processes, I am not sure that is within scope > > In section 7.2, the first sentence says that PA defines a transport. > I don't think so. PB and PT do that. PA is more like a format. This > comment also applies to other parts of the document, like section 5.2.1. The text in Section 7.2 seems like a typo will be edited. The first sentence in Section 5.2.1 does mention "a protocol that carries attribute messages" which needs to be cleaned up. Section 5.2.1 does try to clarify the scope of the PA protocol "The PA protocol is a message oriented lightweight wrapper around a set of attributes being exchanged. This wrapper may indicate the purpose of attributes within the message" > > Requirement PA-1 says "The PA protocol MUST support transport of the > required (standard) attributes defined in the data model." But there's > no data model any more, just standard and vendor-specific attributes. > I think we should have PA-1 require support for the standard attributes > and PA-2 can cover the vendor-specific attributes. Agreed. Would deleting the text " defined in the data model" from PA-1 address this comment ? > > Requirement PB-1 lists some specific messages and says the PB protocol > must be capable of carrying those. I think it should instead just say > that the PB protocol muse be capable of carrying all PA msgs and also > standard & vendor-specific non-PA messages. Agreed. This text should have been addressed as part of our -02 revision since we decided to move away from attribute types. > > Requirement PB-2 should not talk about peer Posture Collectors and > Posture > Validators. Instead, it should explicitly support the idea that one > Posture > Collector or Posture Validator may map to several of the other. Agreed. I think this comment should be addressed as part of editorial suggestions for your previous comment on 5.1.2.1. > > Requirements PT-7 and PT-8 are already covered better by requirements > C-2 and C-3. We shouldn't have PT requirements for these since this > implies that all PT protocols MUST support these use cases. We should > allow some PT protocols to specialize in one use case or another. I agree with your comment about C-2 & PT-7 but I would suggest that we examine C-2 as a common requirement (rather than deleting PT-7) since the ability to perform assessment prior to normal network access being granted to an endpoint depends completely on whether the PT can support such a capability. Requirements C-3 and PT-8 might not be identical, since C-3 specifies the need to support client or server triggered re-assessment and PT-8 requires the PT protocol to support creation of a communication channel based on either end of the channel initiating the connection request. PT-8 will be required for use cases beyond re-assessment. I am not completely clear about your comment about specialization of PT protocols since the charter requires us to specify one mandatory to implement PT protocol that will probably have to meet all requirements ? > > Section 8.3.4 refers to "carrier protocols". Those are in PT now so > we shouldn't be referring to them separately. We used the term "carrier protocol" to refer to protocols that might carry the PT, for e.g. EAPoL & RADIUS would be a carrier protocol for EAP. Do you consider EAPol, RADIUS & EAP as all being part of the PT. > > In section 9.1, I think the phrase "explicitly not" should be "not > explicitly". At least, I hope so! You are right. I think it is a typo. In the context of the section, I think the text intends to say that attributes that are not explicitly shared by the user will result in a notification regards, kaushik > > > _______________________________________________ > 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 Fri Jun 22 17:11:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qPH-0006uU-80; Fri, 22 Jun 2007 17:11:03 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I1qPG-0006tv-8A for nea-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 17:11:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qPF-0006t3-Sl for nea@ietf.org; Fri, 22 Jun 2007 17:11:01 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1qPF-0005KR-7R for nea@ietf.org; Fri, 22 Jun 2007 17:11:01 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 22 Jun 2007 14:11:00 -0700 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] Substantive comments Date: Fri, 22 Jun 2007 17:11:07 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Substantive comments Thread-Index: AcezeVXLYnOS1kwmTYSpXFuoAujCwgA3qvJMAB3BXWA= References: From: "Stephen Hanna" To: "Kaushik Narayan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 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 for your response, Kaushik. My responses are below, marked with . Take care, Steve=20 -----Original Message----- From: Kaushik Narayan [mailto:kaushik@cisco.com]=20 Sent: Thursday, June 21, 2007 7:01 PM To: Stephen Hanna; nea@ietf.org Subject: Re: [Nea] Substantive comments Hi Steve, Thanks for your comments. Please find my response inline. On 6/20/07 1:26 PM, "Stephen Hanna" wrote: > I have a lot of non-substantive comments (typos and such) on > the latest NEA requirements draft so I have divided my comments > into two emails: one with substantive comments (this one) and > another that I'll send in a minute with only minor comments. >=20 > Thanks, >=20 > Steve >=20 > ------------- >=20 > Section 5.1.1.1 says "Each Posture Collector will be associated > with an identifier..." Depending on how things work, there may > be more than one identifier per Posture Collector so I think we > should say "...associated with one or more identifiers...". > This comment applies to other parts of the document as well, such as > section 5.1.2.1. Agreed. The text was meant to convey that there needs to be a mechanism to uniquely identify each posture collector. Will the following edit address your comment. "Each Posture Collector will be associated with one or more identifiers that will be used to uniquely identify the posture collector". Actually, I would prefer to just change the phrase "an identifier" to "one or more identifiers". Then the text would read: Each Posture Collector will be associated with one or more identifiers that enables it to be specified as the destination in a PA message. I don't think it's necessary for each Posture Collector to have a unique identifier. It's just necessary to be able to route messages to it. Later in that paragraph, it says that the identifier may be "a function of the attribute messages the collector desires to receive (e.g. message type subscription)." I'm a fan of that approach and don't want to see the text changed to make it impossible, as I think your proposed edit would do. >=20 > Section 5.1.2.1 talks about a Posture Validator's "corresponding > Posture Collector". I don't think there will always be a one-to-one > mapping from one Posture Collector to one Posture Validator. One > Posture Collector may be able to handle Anti-Virus and Personal > Firewall messages while another may only be able to handle Anti-Virus. > The same holds true for Posture Validators. This comment applies > to other parts of the document as well, like section 5.2.1. >=20 I agree that the text may be misleading but we certainly did not imply a 1-to-1 relationship. Will the following edit (and similar edits in other places) address the comment "A Posture Validator is a component that is responsible for handling Posture Attributes from corresponding Posture Collector(s). A Posture Validator can handle Posture Attributes from one or more Posture Collector(s) and vice-versa". Yes, that is great! Thanks. > In section 5.2.2, PB should be able to carry non-PA messages other > than the global assessment decision. For example, it may be useful > to have PB carry information about the user's preferred language. > That way, this information can be made available to all Posture > Validators so they can send any messages in the preferred language. Agreed. We have discussed the possibility that the PB layer might require to handle additional attributes in the future and I agree that we should have text to indicate that possibility. Very good! Thanks. >=20 > The first paragraph of section 5.3 says "The NEA WG will define a > common (standard) set of attributes that are expected to be supported > by all Posture Collectors." I don't think we want to require all > Posture Collectors to support all of the standard attributes, do we? >=20 I am not sure that we need all posture collectors to support all standard attributes infact I am not sure we are completely settled on how the standard posture attributes are handled. I think we should get rid of the second part of that sentence and just state that " The NEA WG will define a common (standard) set of attributes that will be present in all NEA deployments irrespective of vendor specific extensions" =20 I agree with most of what you said except this new text: "will be present in all NEA deployments". I suspect that some attributes will not be needed for some NEA deployments. I suggest this alternative text for that sentence: "The NEA WG will define a common (standard) set of attributes that will be widely used for maximum interoperability but Posture Collectors may support=20 additional vendor-specific attributes." How's that? > In section 7.1, requirement C-4 should require that NEA protocols > include protection against attacks by endpoints. I am not sure about the comment. An endpoint is an intermediary in the network and hence covered by the existing text. Are you referring to attacks on the NEA client hosted on the endpoint from other endpoint processes, I am not sure that is within scope I don't think the endpoint is an intermediary. According to Merriam-Webster, an intermediary is (among other meanings) one who is at a middle place. The endpoint is not an intermediary. It's one of the endpoints. So attacks by the endpoint on the NEA Server or other parts of the system are not covered by the current text. They should be. Otherwise, a nasty or infected endpoint could bring down the whole system. >=20 > In section 7.2, the first sentence says that PA defines a transport. > I don't think so. PB and PT do that. PA is more like a format. This > comment also applies to other parts of the document, like section 5.2.1. The text in Section 7.2 seems like a typo will be edited. The first sentence in Section 5.2.1 does mention "a protocol that carries attribute messages" which needs to be cleaned up. Section 5.2.1 does try to clarify the scope of the PA protocol "The PA protocol is a message oriented lightweight wrapper around a set of attributes being exchanged. This wrapper may indicate the purpose of attributes within the message" I agree with the text from section 5.2.1 that you cited. If you can clean up section 7.2 to match, I'd appreciate it. >=20 > Requirement PA-1 says "The PA protocol MUST support transport of the > required (standard) attributes defined in the data model." But there's > no data model any more, just standard and vendor-specific attributes. > I think we should have PA-1 require support for the standard attributes > and PA-2 can cover the vendor-specific attributes. Agreed. Would deleting the text " defined in the data model" from PA-1 address this comment ? =20 Yes, that would do it. Thanks. >=20 > Requirement PB-1 lists some specific messages and says the PB protocol > must be capable of carrying those. I think it should instead just say > that the PB protocol muse be capable of carrying all PA msgs and also > standard & vendor-specific non-PA messages. Agreed. This text should have been addressed as part of our -02 revision since we decided to move away from attribute types. OK, great. >=20 > Requirement PB-2 should not talk about peer Posture Collectors and > Posture > Validators. Instead, it should explicitly support the idea that one > Posture > Collector or Posture Validator may map to several of the other. Agreed. I think this comment should be addressed as part of editorial suggestions for your previous comment on 5.1.2.1. Good, good. >=20 > Requirements PT-7 and PT-8 are already covered better by requirements > C-2 and C-3. We shouldn't have PT requirements for these since this > implies that all PT protocols MUST support these use cases. We should > allow some PT protocols to specialize in one use case or another. I agree with your comment about C-2 & PT-7 but I would suggest that we examine C-2 as a common requirement (rather than deleting PT-7) since the ability to perform assessment prior to normal network access being granted to an endpoint depends completely on whether the PT can support such a capability. Requirements C-3 and PT-8 might not be identical, since C-3 specifies the need to support client or server triggered re-assessment and PT-8 requires the PT protocol to support creation of a communication channel based on either end of the channel initiating the connection request. PT-8 will be required for use cases beyond re-assessment. I am not completely clear about your comment about specialization of PT protocols since the charter requires us to specify one mandatory to implement PT protocol that will probably have to meet all requirements ? Hmmm. I guess this raises a larger question. Do we want to require the mandatory to implement PT protocol to support both assessment before and during network access and to support both client-triggered and server-triggered reassessment? That's a tall order! Personally, I think we should not expect one protocol to do all of these things. But probably this should be discussed on a separate email thread so it gets broader visibility. >=20 > Section 8.3.4 refers to "carrier protocols". Those are in PT now so > we shouldn't be referring to them separately. We used the term "carrier protocol" to refer to protocols that might carry the PT, for e.g. EAPoL & RADIUS would be a carrier protocol for EAP. Do you consider EAPol, RADIUS & EAP as all being part of the PT. =20 I don't think they're called out separately in our reference model so yes, I would consider them to be part of PT unless we want to call them out separately in the reference model. >=20 > In section 9.1, I think the phrase "explicitly not" should be "not > explicitly". At least, I hope so! You are right. I think it is a typo. In the context of the section, I think the text intends to say that attributes that are not explicitly shared by the user will result in a notification Good. That's what I thought you wanted to say but the current text says something different. regards, kaushik >=20 >=20 > _______________________________________________ > 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 Fri Jun 22 20:02:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1t5I-00067x-Mo; Fri, 22 Jun 2007 20:02:36 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I1t5H-0005zH-Fp for nea-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 20:02:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1t5H-0005xE-4d for nea@ietf.org; Fri, 22 Jun 2007 20:02:35 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1t5G-00027x-D3 for nea@ietf.org; Fri, 22 Jun 2007 20:02:35 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Jun 2007 17:02:34 -0700 X-IronPort-AV: i="4.16,453,1175497200"; d="scan'208"; a="170598875:sNHT55590471" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5N02XER014207; Fri, 22 Jun 2007 17:02:33 -0700 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 l5N02Xka014531; Sat, 23 Jun 2007 00:02:33 GMT 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); Fri, 22 Jun 2007 17:02:33 -0700 Received: from 171.69.75.129 ([171.69.75.129]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Sat, 23 Jun 2007 00:02:33 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 22 Jun 2007 17:02:32 -0700 Subject: Re: [Nea] Substantive comments From: Kaushik Narayan To: Stephen Hanna , Message-ID: Thread-Topic: [Nea] Substantive comments Thread-Index: AcezeVXLYnOS1kwmTYSpXFuoAujCwgA3qvJMAB3BXWAAFrEu7w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Jun 2007 00:02:33.0694 (UTC) FILETIME=[CCC297E0:01C7B529] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7684; t=1182556953; x=1183420953; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20Kaushik=20Narayan=20 |Subject:=20Re=3A=20[Nea]=20Substantive=20comments |Sender:=20; bh=RgAje12CuTzfFhdmmVkipEZSpOLkrb4HnFHXL4IX+lE=; b=d8kRBrvvLOwFeVKsRC7Ddtok2HlYcGxoaShbVie0VFwFWCMraWr+4PXE3hX6+zfDkALzc7PM fyQfhhYtXjmCBBCBTQ0XayCPtM5ipHqAz65x527D4PrG6QBfKtGjW19l; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 1.6 (+) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 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 Steve, Please find my response inline marked with the tag . I have snipped some of the text to focus on comments that require a response. >> Section 5.1.1.1 says "Each Posture Collector will be associated >> with an identifier..." Depending on how things work, there may >> be more than one identifier per Posture Collector so I think we >> should say "...associated with one or more identifiers...". >> This comment applies to other parts of the document as well, such as >> section 5.1.2.1. > > > > > Agreed. The text was meant to convey that there needs to be a mechanism > to > uniquely identify each posture collector. Will the following edit > address > your comment. > > "Each Posture Collector will be associated with one or more identifiers > that > will be used to uniquely identify the posture collector". > > > > > Actually, I would prefer to just change the phrase "an identifier" to > "one or more identifiers". Then the text would read: > > Each Posture Collector will be associated with one or more > identifiers > that enables it to be specified as the destination in a PA message. > > I don't think it's necessary for each Posture Collector to have a unique > identifier. It's just necessary to be able to route messages to it. > Later > in that paragraph, it says that the identifier may be "a function of the > attribute messages the collector desires to receive (e.g. message type > subscription)." I'm a fan of that approach and don't want to see the > text > changed to make it impossible, as I think your proposed edit would do. > > > I was suggesting uniqueness as a property of the identifier to allow Posture Broker Clients to route Attribute messages to the right Posture Collector. I wasn't suggesting a globally unique identifier that needs to be statically allocated which would preclude the posture broker assigning these IDs or IDs derived from attribute messages based on subscription. I will probably just stay with your suggestion to avoid the use of the term unique since it might be confusing. > >> >> The first paragraph of section 5.3 says "The NEA WG will define a >> common (standard) set of attributes that are expected to be supported >> by all Posture Collectors." I don't think we want to require all >> Posture Collectors to support all of the standard attributes, do we? >> > > > > > I am not sure that we need all posture collectors to support all > standard > attributes infact I am not sure we are completely settled on how the > standard posture attributes are handled. > > I think we should get rid of the second part of that sentence and just > state > that " The NEA WG will define a common (standard) set of attributes that > will be present in all NEA deployments irrespective of vendor specific > extensions" > > > > > > I agree with most of what you said except this new text: "will be > present > in all NEA deployments". I suspect that some attributes will not be > needed > for some NEA deployments. I suggest this alternative text for that > sentence: > "The NEA WG will define a common (standard) set of attributes that will > be > widely used for maximum interoperability but Posture Collectors may > support > additional vendor-specific attributes." How's that? > > Sounds good. Thanks. > >> In section 7.1, requirement C-4 should require that NEA protocols >> include protection against attacks by endpoints. > > > > I am not sure about the comment. An endpoint is an intermediary in the > network and hence covered by the existing text. Are you referring to > attacks > on the NEA client hosted on the endpoint from other endpoint processes, > I am > not sure that is within scope > > > > > > I don't think the endpoint is an intermediary. According to > Merriam-Webster, > an intermediary is (among other meanings) one who is at a middle place. > The endpoint is not an intermediary. It's one of the endpoints. So > attacks > by the endpoint on the NEA Server or other parts of the system are not > covered by the current text. They should be. Otherwise, a nasty or > infected > endpoint could bring down the whole system. > > > Fair point. We never intended to rule out endpoints when we used the term intermediary. Would the following text work " NEA protocols MUST provide protection against active and passive attacks by intermediaries and other endpoints including protection to prevent replay based attacks. " > >> >> Requirements PT-7 and PT-8 are already covered better by requirements >> C-2 and C-3. We shouldn't have PT requirements for these since this >> implies that all PT protocols MUST support these use cases. We should >> allow some PT protocols to specialize in one use case or another. > > > > > I agree with your comment about C-2 & PT-7 but I would suggest that we > examine C-2 as a common requirement (rather than deleting PT-7) since > the > ability to perform assessment prior to normal network access being > granted > to an endpoint depends completely on whether the PT can support such a > capability. > > Requirements C-3 and PT-8 might not be identical, since C-3 specifies > the > need to support client or server triggered re-assessment and PT-8 > requires > the PT protocol to support creation of a communication channel based on > either end of the channel initiating the connection request. PT-8 will > be > required for use cases beyond re-assessment. > > I am not completely clear about your comment about specialization of PT > protocols since the charter requires us to specify one mandatory to > implement PT protocol that will probably have to meet all requirements ? > > > > > > Hmmm. I guess this raises a larger question. Do we want to require > the mandatory to implement PT protocol to support both assessment > before and during network access and to support both client-triggered > and server-triggered reassessment? That's a tall order! Personally, > I think we should not expect one protocol to do all of these things. > But probably this should be discussed on a separate email thread so > it gets broader visibility. > > This might require us to think about the use cases that are mandatory to support for the PT. I agree that this needs more thought and wider discussion within the WG. > >> >> Section 8.3.4 refers to "carrier protocols". Those are in PT now so >> we shouldn't be referring to them separately. > > > > We used the term "carrier protocol" to refer to protocols that might > carry > the PT, for e.g. EAPoL & RADIUS would be a carrier protocol for EAP. Do > you > consider EAPol, RADIUS & EAP as all being part of the PT. > > > > > > I don't think they're called out separately in our reference model > so yes, I would consider them to be part of PT unless we want to > call them out separately in the reference model. > > > >> You are right. The reference model does not call out the notion of carrier protocols and we should largely stay consistent with that. regards, kaushik _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Jun 24 15:42:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2XyM-0005Iv-0f; Sun, 24 Jun 2007 15:42:10 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I2XyL-0005Iq-3U for nea-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 15:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2XyK-0005Ii-PR for nea@ietf.org; Sun, 24 Jun 2007 15:42:08 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2XyK-0007vJ-6r for nea@ietf.org; Sun, 24 Jun 2007 15:42:08 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 24 Jun 2007 12:42:06 -0700 X-IronPort-AV: i="4.16,456,1175497200"; d="scan'208"; a="24483481:sNHT58666552" 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] Substantive comments Date: Sun, 24 Jun 2007 15:42:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Substantive comments Thread-Index: AcezeVXLYnOS1kwmTYSpXFuoAujCwgA3qvJMAB3BXWAAFrEu7wBIOO1A References: From: "Stephen Hanna" To: "Kaushik Narayan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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 I added comments where necessary (marked with ) and snipped areas where we seem to have reached agreement. Thanks, Steve=20 -----Original Message----- From: Kaushik Narayan [mailto:kaushik@cisco.com]=20 Sent: Friday, June 22, 2007 8:03 PM To: Stephen Hanna; nea@ietf.org Subject: Re: [Nea] Substantive comments Hi Steve, Please find my response inline marked with the tag . I have snipped some of the text to focus on comments that require a response. >> Section 5.1.1.1 says "Each Posture Collector will be associated >> with an identifier..." Depending on how things work, there may >> be more than one identifier per Posture Collector so I think we >> should say "...associated with one or more identifiers...". >> This comment applies to other parts of the document as well, such as >> section 5.1.2.1. >=20 >=20 > >=20 > Agreed. The text was meant to convey that there needs to be a mechanism > to > uniquely identify each posture collector. Will the following edit > address > your comment. >=20 > "Each Posture Collector will be associated with one or more identifiers > that > will be used to uniquely identify the posture collector". >=20 > >=20 > > Actually, I would prefer to just change the phrase "an identifier" to > "one or more identifiers". Then the text would read: >=20 > Each Posture Collector will be associated with one or more > identifiers > that enables it to be specified as the destination in a PA message. >=20 > I don't think it's necessary for each Posture Collector to have a unique > identifier. It's just necessary to be able to route messages to it. > Later > in that paragraph, it says that the identifier may be "a function of the > attribute messages the collector desires to receive (e.g. message type > subscription)." I'm a fan of that approach and don't want to see the > text > changed to make it impossible, as I think your proposed edit would do. >=20 > >=20 I was suggesting uniqueness as a property of the identifier to allow Posture Broker Clients to route Attribute messages to the right Posture Collector. I wasn't suggesting a globally unique identifier that needs to be statically allocated which would preclude the posture broker assigning these IDs or IDs derived from attribute messages based on subscription. I will probably just stay with your suggestion to avoid the use of the term unique since it might be confusing. Ah, so you meant unique only within the NEA Client or NEA Server. I'm afraid I don't even agree with that. There may be several Posture Validators for AV messages on the NEA Server if an organization wants to recognize the vendor specific messages of several AV vendors. So I think it's best to avoid the idea that these identifiers will be unique. >> In section 7.1, requirement C-4 should require that NEA protocols >> include protection against attacks by endpoints. >=20 > >=20 > I am not sure about the comment. An endpoint is an intermediary in the > network and hence covered by the existing text. Are you referring to > attacks > on the NEA client hosted on the endpoint from other endpoint processes, > I am > not sure that is within scope >=20 > >=20 > >=20 > I don't think the endpoint is an intermediary. According to > Merriam-Webster, > an intermediary is (among other meanings) one who is at a middle place. > The endpoint is not an intermediary. It's one of the endpoints. So > attacks > by the endpoint on the NEA Server or other parts of the system are not > covered by the current text. They should be. Otherwise, a nasty or > infected > endpoint could bring down the whole system. >=20 > >=20 Fair point. We never intended to rule out endpoints when we used the term intermediary. Would the following text work " NEA protocols MUST provide protection against active and passive attacks by intermediaries and other endpoints including protection to prevent replay based attacks. " I'm OK with your text but find the phrase "other endpoints" confusing. Some intermediaries may not have an IP address (like an L2 bridge). And within the NEA Reference Model, the endpoint is generally the device being assessed. I suggest removing the word "other" from your text. >> Requirements PT-7 and PT-8 are already covered better by requirements >> C-2 and C-3. We shouldn't have PT requirements for these since this >> implies that all PT protocols MUST support these use cases. We should >> allow some PT protocols to specialize in one use case or another. >=20 >=20 > >=20 > I agree with your comment about C-2 & PT-7 but I would suggest that we > examine C-2 as a common requirement (rather than deleting PT-7) since > the > ability to perform assessment prior to normal network access being > granted > to an endpoint depends completely on whether the PT can support such a > capability. >=20 > Requirements C-3 and PT-8 might not be identical, since C-3 specifies > the > need to support client or server triggered re-assessment and PT-8 > requires > the PT protocol to support creation of a communication channel based on > either end of the channel initiating the connection request. PT-8 will > be > required for use cases beyond re-assessment. >=20 > I am not completely clear about your comment about specialization of PT > protocols since the charter requires us to specify one mandatory to > implement PT protocol that will probably have to meet all requirements ? >=20 > >=20 > >=20 > Hmmm. I guess this raises a larger question. Do we want to require > the mandatory to implement PT protocol to support both assessment > before and during network access and to support both client-triggered > and server-triggered reassessment? That's a tall order! Personally, > I think we should not expect one protocol to do all of these things. > But probably this should be discussed on a separate email thread so > it gets broader visibility. >=20 > This might require us to think about the use cases that are mandatory to support for the PT. I agree that this needs more thought and wider discussion within the WG. OK, I'll start a separate thread. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Jun 24 15:42:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2XyZ-0005PM-6W; Sun, 24 Jun 2007 15:42:23 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I2XyX-0005PH-Ne for nea-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 15:42:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2XyX-0005P9-EA for nea@ietf.org; Sun, 24 Jun 2007 15:42:21 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2XyW-0007vd-73 for nea@ietf.org; Sun, 24 Jun 2007 15:42:21 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 24 Jun 2007 12:42:19 -0700 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 Date: Sun, 24 Jun 2007 15:42:25 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements for MTI PT Thread-Index: Ace2l8oZoK0MTg91TyuAPpvhruxbTg== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Nea] Requirements for MTI PT 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 I would like to start a separate thread on this question, which came up during discussion of draft-ietf-nea-requirements-02.txt: > Do we want to require the mandatory to implement (MTI) PT protocol to > support both assessment before and during network access and to support > both client-triggered and server-triggered reassessment? Personally, I think this is a tall order. It would be nice to have one MTI protocol that supports all these things. Maybe it should be preferred but I don't think we should make it a requirement. What do you think? Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jun 25 01:20:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2h03-0007Zt-K2; Mon, 25 Jun 2007 01:20:31 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I2h02-0007Yj-49 for nea-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 01:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2h00-0007Yb-NB for nea@ietf.org; Mon, 25 Jun 2007 01:20:28 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2h00-0004uQ-9k for nea@ietf.org; Mon, 25 Jun 2007 01:20:28 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2007 22:20:27 -0700 X-IronPort-AV: i="4.16,457,1175497200"; d="scan'208"; a="171339451:sNHT47847753" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5P5KR93004199; Sun, 24 Jun 2007 22:20:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5P5KIXJ004795; Mon, 25 Jun 2007 05:20:27 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Jun 2007 22:20:18 -0700 Received: from 10.21.80.182 ([10.21.80.182]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Mon, 25 Jun 2007 05:20:17 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 24 Jun 2007 22:20:16 -0700 Subject: Re: [Nea] Substantive comments From: Kaushik Narayan To: Stephen Hanna , Message-ID: Thread-Topic: [Nea] Substantive comments Thread-Index: AcezeVXLYnOS1kwmTYSpXFuoAujCwgA3qvJMAB3BXWAAFrEu7wBIOO1AACd1Cts= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 05:20:18.0826 (UTC) FILETIME=[854A5EA0:01C7B6E8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3506; t=1182748827; x=1183612827; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20Kaushik=20Narayan=20 |Subject:=20Re=3A=20[Nea]=20Substantive=20comments |Sender:=20; bh=qGkUZ9WqSLRoBFNycDtsD6TuJFSng2AzVhudKcCtp1I=; b=LaQ3JJT/JX5qlc8xSU94XkFOQVb+I4MO3h1xr57Y7cUOr33bWmgwFft7hXUDjRJQIhYL2Dd6 vSl3DoFgxWg8cmP/QzPHWR6BqiUrS3QYB19tH77dx7/TmnU9zAlkcgW7; Authentication-Results: sj-dkim-2; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Steve, Please find my response inline tagged > > > > I was suggesting uniqueness as a property of the identifier to allow > Posture > Broker Clients to route Attribute messages to the right Posture > Collector. I > wasn't suggesting a globally unique identifier that needs to be > statically > allocated which would preclude the posture broker assigning these IDs or > IDs > derived from attribute messages based on subscription. > > I will probably just stay with your suggestion to avoid the use of the > term > unique since it might be confusing. > > > > > > Ah, so you meant unique only within the NEA Client or NEA Server. I'm > afraid > I don't even agree with that. There may be several Posture Validators > for AV > messages on the NEA Server if an organization wants to recognize the > vendor > specific messages of several AV vendors. So I think it's best to avoid > the > idea that these identifiers will be unique. > > > I am not completely clear about your comment since within a NEA server/client the Posture Broker (client/server) will use these identifiers to distinguish between different posture validators/collectors. Anyway, I think we can avoid the term "unique identifier" given the confusion. >>> In section 7.1, requirement C-4 should require that NEA protocols >>> include protection against attacks by endpoints. >> >> >> >> I am not sure about the comment. An endpoint is an intermediary in the >> network and hence covered by the existing text. Are you referring to >> attacks >> on the NEA client hosted on the endpoint from other endpoint > processes, >> I am >> not sure that is within scope >> >> >> >> >> >> I don't think the endpoint is an intermediary. According to >> Merriam-Webster, >> an intermediary is (among other meanings) one who is at a middle > place. >> The endpoint is not an intermediary. It's one of the endpoints. So >> attacks >> by the endpoint on the NEA Server or other parts of the system are not >> covered by the current text. They should be. Otherwise, a nasty or >> infected >> endpoint could bring down the whole system. >> >> >> > > > > > Fair point. We never intended to rule out endpoints when we used the > term > intermediary. Would the following text work > > " NEA protocols MUST provide protection against active and passive > attacks > by intermediaries and other endpoints including protection to prevent > replay > based attacks. " > > > > > > I'm OK with your text but find the phrase "other endpoints" confusing. > Some intermediaries may not have an IP address (like an L2 bridge). And > within the NEA Reference Model, the endpoint is generally the device > being assessed. I suggest removing the word "other" from your text. > > I included the term "other endpoint" since I wanted to clarify that we won't be addressing attacks initiated within the same endpoint, i.e. Attacks on the NEA client by other processes within the same endpoint. I will avoid the use of the term "other" since it is confusing and try to clarify this explicitly. regards, kaushik _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea