From nea-bounces@ietf.org Sun Mar 04 22:58: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 1HO4L5-0003n8-68; Sun, 04 Mar 2007 22:58:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO4L3-0003mu-I9 for nea@ietf.org; Sun, 04 Mar 2007 22:58:17 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO4L1-0005mw-Vh for nea@ietf.org; Sun, 04 Mar 2007 22:58:17 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 87A0C38C03C for ; Sun, 4 Mar 2007 19:58:15 -0800 (PST) X-AuditID: d80ac287-a2231bb000002978-57-45eb95570388 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 49DB9348003 for ; Sun, 4 Mar 2007 19:58:15 -0800 (PST) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HO4L1-0001UY-5t for nea@ietf.org; Sun, 04 Mar 2007 19:58:15 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 4 Mar 2007 19:58:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Mar 2007 19:58:13 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A0264269D@SVL1XCHCLUPIN02.enterprise.veritas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working towards -01 draft: call for comments and schedule Thread-Index: AcdSAmclqxn14MhbRe66G7q8Y/t5iwM15ahQ From: "Paul Sangster" To: X-OriginalArrivalTime: 05 Mar 2007 03:58:14.0939 (UTC) FILETIME=[8028D6B0:01C75EDA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Subject: [Nea] RE: Working towards -01 draft: call for comments and schedule X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2107833069==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============2107833069== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75EDA.800F3430" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75EDA.800F3430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a quick update that the design team has submitted the -01 draft (this past friday) for publication. We attempted to include much of the feedback we had received thru last week and welcome additional comments on the -00 draft until -01 is published. ________________________________ From: Paul Sangster=20 Sent: Friday, February 16, 2007 11:41 AM To: nea@ietf.org Subject: Working towards -01 draft: call for comments and schedule =09 =09 So far their have been a number of good discussions on the -00 reqs draft; thanks to those who took the time to participate. It is our hope to get even broader participation so we can better understand where consensus=20 exists and where issues remain. We wish the encourage more WG members to share their review of the draft and provide their constructive feedback. Knowing what sections you believe are going in the right direction=20 and those that need more focus (specifically what issues exist) will=20 help us create a better spec and avoid changing something that many people=20 believe should remain in the spec. =20 On 1/10 the WG chairs requested that we focus our comments on the initial 5 sections and to break up our e-mail comments by section or topic using descriptive subject lines. We would like to continue this practice but=20 also encourage discussion of the Use Case (section 6), Security=20 Considerations (section 8) and Privacy Considerations (section 9) sections. This means we're encouraging comments on the entire draft except section 7=20 allowing us to have a common understanding of the context for the=20 requirements before nailing down the specific requirement wordings. =20 The design team is working towards a goal of submitting the -01 revision by 3/2 (ahead of the Prague I-D cut-off.) Our hope is -01 will be published=20 early enough to allow additional discussion on the alias before the NEA=20 WG meeting. In order to make this schedule we would like to request a 2/24=20 12PM (noon) PST cut-off for comments on -00 so we can update the spec in=20 time. Additional or unresolved discussions of comments at that time will=20 be considered for the -02 revision. =20 Paul ------_=_NextPart_001_01C75EDA.800F3430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just a quick update that the design team has = submitted=20 the -01 draft (this past friday) for publication.  We attempted to = include=20 much of the feedback we had received thru last week and welcome = additional=20 comments on the -00 draft until -01 is = published.

From: Paul Sangster =
Sent: Friday,=20 February 16, 2007 11:41 AM
To: = nea@ietf.org
Subject:=20 Working towards -01 draft: call for comments and = schedule

So far their have been a number of = good=20 discussions on the -00 reqs draft;
thanks to those who took the = time to=20 participate.  It is our hope to get
even broader participation = so we=20 can better understand where consensus
exists and where issues=20 remain.  We wish the encourage more WG members
to share their = review=20 of the draft and provide their constructive
feedback.  Knowing = what=20 sections you believe are going in the right direction
and those = that need=20 more focus (specifically what issues exist) will
help us create a = better=20 spec and avoid changing something that many people
believe should = remain=20 in the spec.
 
On 1/10 the WG chairs requested that = we focus our=20 comments on the initial 5
sections and to break up our e-mail = comments by=20 section or topic using
descriptive subject = lines.  We=20 would like to continue this practice but
also encourage discussion = of the=20 Use Case (section 6), Security
Considerations (section 8) and = Privacy=20 Considerations (section 9) sections.
This means we're encouraging = comments=20 on the entire draft except section 7
allowing us to have a common=20 understanding of the context for the
requirements before nailing = down the=20 specific requirement wordings.
 
The design team is working towards a = goal of=20 submitting the -01 revision
by 3/2 (ahead of the Prague I-D = cut-off.) =20 Our hope is -01 will be published
early enough to allow additional = discussion on the alias before the NEA
WG meeting. In order to = make this=20 schedule we would like to request a 2/24
12PM (noon) PST cut-off = for=20 comments on -00 so we can update the spec in
time.  = Additional or=20 unresolved discussions of comments at that time will
be considered = for the=20 -02 revision.
 
Paul
------_=_NextPart_001_01C75EDA.800F3430-- --===============2107833069== 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 --===============2107833069==-- From nea-bounces@ietf.org Mon Mar 05 00: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 1HO5xK-0006tF-N8; Mon, 05 Mar 2007 00:41:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO5xI-0006tA-Fd for nea@ietf.org; Mon, 05 Mar 2007 00:41:52 -0500 Received: from ccerelbas04.cce.hp.com ([161.114.21.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO5xD-00027K-2q for nea@ietf.org; Mon, 05 Mar 2007 00:41:52 -0500 Received: from G3W0059.americas.hpqcorp.net (g3w0059.americas.hpqcorp.net [16.232.1.16]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id 7300734242; Sun, 4 Mar 2007 23:41:44 -0600 (CST) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by G3W0059.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 05:40:48 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] REQ: sections <= 2 Date: Mon, 5 Mar 2007 05:40:46 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB211011CA0A9@G3W0072.americas.hpqcorp.net> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DC0@SVL1XCHCLUPIN02.enterprise.veritas.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: sections <= 2 Thread-Index: AcdZTR2e0Qu1mxa1QhSnHu644vWgWwAyc7KQATM+p4A= References: <2F2D38A4B8346F48A683750A46BAB2110113C552@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8DC0@SVL1XCHCLUPIN02.enterprise.veritas.com> From: "Sanchez, Mauricio (ProCurve)" To: "Paul Sangster" , X-OriginalArrivalTime: 05 Mar 2007 05:40:48.0107 (UTC) FILETIME=[D3BBC3B0:01C75EE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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="===============0298373205==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============0298373205== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0011_01C75EA5.C4B8D210"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_0011_01C75EA5.C4B8D210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Paul wrote... > We wanted to call out when we were using a defined term vs. the generic > equivalent (roughly equivalent of SHOULD vs should.) Since we use a > few > commonly used words (e.g. Message, Component ...) with a special > meaning > we thought it was important to be clear what was intended. For > sections > that are prior to the terminology section we didn't wish to use defined > terms (since they weren't defined yet) and instead stick with generally > known wordings. Another WG member already pointed out that we missed a > few terms that were used in the abstract (which is fixed in -01.) Perhaps the underlying issue here is not as much the capitalization (which is symptomatic of the issue), but the choice in terminology. Could better choice of terms assuage the need to capitalize? > > > > Section 2 specific comments > > 1. How exactly do policy attributes differ from posture > > attributes? It's unclear to me because of the claim in the > > Policy Attributes describe or reference policies that the Endpoint must > meet to be considered compliant ("must have firewall running > at > least version 1.2.3"). These are sent by the NEA Server (will add text > to mention this.) > > Posture Attributes includes Posture information about a requested > Component (Firewall installed, version 1.5, Firewall running, ...) The > Posture Validator compares this information to its policy to determine > compliance. These are sent by the NEA Client. Ah...so if I this understand correct, policy attributes are used to carry just references to some [named] policy, while posture attributes are explicit posture values. To use a programming analogy it's the case of pass by reference vs. pass by value. If my understanding is correct, then I would suggest that the document describe the fact that policy attributes require the pre-population of policy in endpoint. Otherwise, the policy attributes will likely reference policy that has no particular meaning to the endpoint. This also brings up the question of just how far we expect to standardize policy attributes. While it may not be too difficult to reach consensus on attribute syntax, agreement on semantics, in particular how policy references should be interpreted, may be difficult. > > definition of policy attributes that states that policy > > attributes can be used to establish compliancy without > > divulging posture information. Isn't the exchange of policy > > and compliance attributes in fact a form of posture > > information exchange. > > I presume you mean Policy and Compliance Claim Attributes. In some > sense you could argue this but we felt it was important to be more > clear > about the different types of attributes as they have differing > security, > privacy and operational properties. We found these names very helpful I agree, but again I point out the statement, "...Policy Attributes might be used to enable an NEA client to determine whether the Endpoint is compliant without disclosing Posture information..." Don't you agree that policy and compliance claim attributes in fact do disclose indirectly posture information? I see where the design team is going with policy attributes, but probably went too far in asserting that posture attributes don't disclose [any] endpoint posture information. MS ------=_NextPart_000_0011_01C75EA5.C4B8D210 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMwNTA1NDA0NlowIwYJ KoZIhvcNAQkEMRYEFCD1wABFzEyzdbABxyUeTP6V+lXWMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgJ+LfKTk6rB/mYF8/L4T0GFWjlvxbP3D0+M9tc2fmhqe8+milcxbnWOQtYo1Jz5e +DkFf5txWNVeki4iEzVy6u2c0HHwGQrkZ70iBjm4uZnGc+N2GNNbEmTzz0pvHOcmFbOG6dTcOzGO NdWwdhNDfX89EOYqCFLuRaCX950KLm8EAAAAAAAA ------=_NextPart_000_0011_01C75EA5.C4B8D210-- --===============0298373205== 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 --===============0298373205==-- From nea-bounces@ietf.org Mon Mar 05 01:02: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 1HO6HR-0008De-Jx; Mon, 05 Mar 2007 01:02:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO6HP-0008DR-VK for nea@ietf.org; Mon, 05 Mar 2007 01:02:39 -0500 Received: from ccerelbas01.cce.hp.com ([161.114.21.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO6HK-0004fk-1U for nea@ietf.org; Mon, 05 Mar 2007 01:02:39 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ccerelbas01.cce.hp.com (Postfix) with ESMTP id 52B9D34379; Mon, 5 Mar 2007 00:02:31 -0600 (CST) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 00:02:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] REQ: section 8 Date: Mon, 5 Mar 2007 06:02:02 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB211011CA0B7@G3W0072.americas.hpqcorp.net> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DE5@SVL1XCHCLUPIN02.enterprise.veritas.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: section 8 Thread-Index: AcdZTZ9vKINEVuojQAC6aQZLQy8vJAA1bpLAATHlDeA= References: <2F2D38A4B8346F48A683750A46BAB2110113C556@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8DE5@SVL1XCHCLUPIN02.enterprise.veritas.com> From: "Sanchez, Mauricio (ProCurve)" To: "Paul Sangster" , X-OriginalArrivalTime: 05 Mar 2007 06:02:04.0956 (UTC) FILETIME=[CCCB75C0:01C75EEB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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="===============0424349114==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============0424349114== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0020_01C75EA8.BD7A1600"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_0020_01C75EA8.BD7A1600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > > > My comments on section 8: > > 1. Section 8.1, ".NEA client frequently is expected to trust > > the network infrastructure not to misuse any disclosed > > Posture information." sentence: > > Doesn't the client always need to trust that the network > > infrastructure isn't going to misuse the posture information? > > What are some examples where it doesn't need to trust the > > infrastructure? > > We could make this absolute but their could be situations where the > client didn't disclose any sensitive information that it cares about > being disclosed to other parties (e.g. when it sends only Compliance > Claim Attributes.) Another option might be that the employment > agreement the Endpoint User signed states that the Endpoint Owner (who > is also the network Owner) can make use of the information in any way > it > sees fit. In general, I agree with your comment but wanted to leave > the > door open for (hopefully!) less common situations. Maybe we should > change "frequently" to "normally"? I support the word change to clarify the sentence. > > 2. Section 8.1.3 - Isn't there a version of the "lying > > client" problem that is applicable to servers? What if my > > NEA server were compromised in a way that it no longer could > > be trusted to function correctly? I'd say each server > > component needs the same protection afforded to clients for > > the lying client problem. > > Can you explain more? In these examples the server isn't being > assessed > by the client. If it were being assessed, then this would be an issue. > What did you have in mind (is it the server being assessed)? In this > case the NEA Server would run on the Endpoint and the NEA Client on the > "server". A NEA client doesn't assess the NEA server from a posture compliance perspective, but doesn't the NEA client need to minimally establish that it's speaking to a valid NEA server? If I were running a NEA client on my laptop I wouldn't reply to requests from just any arbitrary NEA server. I'd first want to make sure that I was talking to a valid NEA server before handing over my posture info. Cheers, MS ------=_NextPart_000_0020_01C75EA8.BD7A1600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMwNTA2MDIwMlowIwYJ KoZIhvcNAQkEMRYEFFbbavwebmVwz+/ErznJ9q4kdeF8MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgNSYg/O3OcotfI7WslBz65AmGOS9yMFe2hD6ZGPYOtCSqkXZqbXopgnyu/EBFS1J vHcbSsjVAE9kRwEgF4Du+JtPVPBsm7bv58kYsd5gfUrXdckpZ1NuQlIYlRrO0xZ3YS1mkicjP0oQ JbO7bLf0ougD/UwZ3rQdi4Uk6ewf0xg+AAAAAAAA ------=_NextPart_000_0020_01C75EA8.BD7A1600-- --===============0424349114== 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 --===============0424349114==-- From nea-bounces@ietf.org Mon Mar 05 01:03: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 1HO6Hm-0000Bm-0u; Mon, 05 Mar 2007 01:03:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO6Hk-0008WK-Io for nea@ietf.org; Mon, 05 Mar 2007 01:03:00 -0500 Received: from ccerelbas01.cce.hp.com ([161.114.21.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO6HK-0004fl-1U for nea@ietf.org; Mon, 05 Mar 2007 01:03:00 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ccerelbas01.cce.hp.com (Postfix) with ESMTP id 5200234371; Mon, 5 Mar 2007 00:02:31 -0600 (CST) Received: from cceexb12.americas.cpqcorp.net ([16.81.1.32]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 00:01:28 -0600 Received: from tayexb11.americas.cpqcorp.net ([16.103.130.93]) by cceexb12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 00:01:27 -0600 Received: from tayexg12.americas.cpqcorp.net ([16.103.130.127]) by tayexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 01:01:09 -0500 Received: from tayexb12.americas.cpqcorp.net ([16.103.130.102]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 00:54:34 -0500 Received: from G3W0058.americas.hpqcorp.net ([16.232.1.14]) by tayexb12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 00:54:33 -0500 Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by G3W0058.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 05:54:33 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] REQ: section 6 comments Date: Mon, 5 Mar 2007 05:54:31 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB211011CA0B4@G3W0072.americas.hpqcorp.net> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A025A8DDD@SVL1XCHCLUPIN02.enterprise.veritas.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: section 6 comments Thread-Index: AcdZTWwbN5FEzEn9QOG++FfOr+9CqQAz4axAATMGfTA= References: <2F2D38A4B8346F48A683750A46BAB2110113C554@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8DDD@SVL1XCHCLUPIN02.enterprise.veritas.com> From: "Sanchez, Mauricio (ProCurve)" To: "Paul Sangster" , X-OriginalArrivalTime: 05 Mar 2007 05:54:33.0224 (UTC) FILETIME=[BF8AA080:01C75EEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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="===============0207850506==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============0207850506== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_001B_01C75EA7.B053A690"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_001B_01C75EA7.B053A690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Paul wrote... > > One of the goals of the spec was to broadly describe the problem space > in the use case (examples.) We carefully allocated different aspects > of > the problem space to each of the 5 use case areas. We recognized that > the 1st use case was pretty complex (but is likely a well understood > scenario) so you'll note step 14 doesn't go into the re-assessment > details. If we separated out the remediation it wouldn't make this > much > simpler (removes steps 14-16 only.) Given that re-assessment appears to be covered by other use case examples, the design team may want to consider stripping out 14-16 out. As you point out, the use case is already complex as it is. > > 2. Section 6.1.1.2 - I don't believe step 14 is true. > > After the OS > > Patch validator signals success it's highly unlikely the user > > will physically re-connect to the network to get a > > re-assessment started. I suspect the NEA components have > > some facility to request global re-assessment, right? > > Correct, we'll try to fix the wording. Note however that step 1 > doesn't > mention booting or user interaction just that: "The IT employee's > desktop computer connects to the network...". If it helps we could > address this comment. Ok. I await the new wording. > > 3. Section 6.1.1.3 - Not sure what this section is trying > > to say. This > > section does highlight some characteristics of the example > > scenario, but I don't see how this translates into impact on > > requirements. Consider adding additional discussion to clarify. > > Ok. These are "different aspects of the problem space" mentioned above > that could impact the requirement definitions. Some text to explain > this would be helpful. Agree. > > > > > 4. Section 6.1.2 - What is meant by network service? Isn't the > > scenario described by section 6.1.1 essentially also an > > example of a request for a network service? Please > > compare/contrast somewhere initial network connect and > > request for network service. > > I presume the example given in 6.1.2 wasn't sufficent (detailed > enough)? > One could imagine this being a request to a protected service like the > Financial Portal server which contains very sensitive and mission > critical data. We used the example of VPN to show an L3 (instead of > L7) > service request but as you mention this smells similar to the L2 > initial > network connect example. We could switch it if others feel this is > important. Having clearly differentiated use cases and adjoining examples is extremely desirable. > > 5. Section 6.1.2.1 - This example triggered in my mind a > > new derivative > > use case. Namely, what about a use case that involves the > > need to pass multiple [concurrent] assessments? For example, > > what if I'm a guest at a company that provides guest LAN > > network connectivity as long as I pass muster via NEA. What > > if then I desire to connect back via VPN to my company's > > network that also requires passing security muster via NEA. > > This seems like a realistic and probable use case. Would NEA > > protocols support this? > > Certainly more complicated and I'm not sure this introduces an aspect > of > the problem space that we didn't already cover. I presume this would > just be 2 independent assessments without knowledge of each other (?). Hypothetically speaking, if on describes use case A and use case B, does this mean that use case A+B is automatically supported? I would say that it's not automatic in most cases. You make the valid point that in the (A+B) case that I postulate there's a need to have 2 independent assessments with knowledge of each other. In which of the existing use cases does this requirement get covered? Cheers, MS ------=_NextPart_000_001B_01C75EA7.B053A690 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMwNTA1NTQzMVowIwYJ KoZIhvcNAQkEMRYEFInhRS7DGdPVJlBwEr3fccvVcC+uMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgCeyMXXygjpjSsqo7xpoZn0I0RG9kiAvXI7ZkpITTucP/FErPHzKWi61AbCSf3MK JB296p2eRIEr2WP9nZB3LMZ4/gMDYbO7ZZjoxJ57h7TQbIKHWRzA06HwQhbpoIm2qv3FbX+pMIsj PBX0h+XYKJpaErUCahHTSGEADSpN9GBZAAAAAAAA ------=_NextPart_000_001B_01C75EA7.B053A690-- --===============0207850506== 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 --===============0207850506==-- From nea-bounces@ietf.org Mon Mar 05 01:47:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO6yz-0006vc-0C; Mon, 05 Mar 2007 01:47:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO6yx-0006vT-Hb for nea@ietf.org; Mon, 05 Mar 2007 01:47:39 -0500 Received: from ccerelbas02.cce.hp.com ([161.114.21.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO6ys-0002wq-RA for nea@ietf.org; Mon, 05 Mar 2007 01:47:39 -0500 Received: from G3W0060.americas.hpqcorp.net (g3w0060.americas.hpqcorp.net [16.232.1.19]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 55CEE3423D; Mon, 5 Mar 2007 00:47:32 -0600 (CST) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by G3W0060.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 06:47:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] REQ: Section 5 comments Date: Mon, 5 Mar 2007 06:47:13 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB211011CA0BF@G3W0072.americas.hpqcorp.net> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A025A8E2E@SVL1XCHCLUPIN02.enterprise.veritas.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 5 comments Thread-Index: AcdZTUcDOBr2jfMtQ6a6RDSRtgZTNAA58FdgAS3YlVA= References: <2F2D38A4B8346F48A683750A46BAB2110113C553@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8E2E@SVL1XCHCLUPIN02.enterprise.veritas.com> From: "Sanchez, Mauricio (ProCurve)" To: "Paul Sangster" , X-OriginalArrivalTime: 05 Mar 2007 06:47:14.0454 (UTC) FILETIME=[1BC80B60:01C75EF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d 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="===============1227816961==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============1227816961== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0025_01C75EAF.0CC2CFD0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_0025_01C75EAF.0CC2CFD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Paul wrote... > > Which virtualization model are you concerned about? Is it hypervisor > style (multi guest OSes and/or virtual appliances) as per a Xen model? > If so, why couldn't the NEA Client just run in each guest OS and > provide > Posture like it would in a non-virtualized environment? If multiple > guest OSes exist, each normally have their own network interfaces > (possibly [para]virtualized) but they could report their Posture when > requested on their interface (or when attempting to connect to the > network.) The primary difference I see is the potential lack of > Posture > about the hypervisor layer but this could be addressed in different > ways. > This might be an interesting dialog to have on the alias to determine > if > we need to push this out of scope or whether this is similar enough to > our model that it could remain in scope and be discussed. So it sounds like you're of the mindset that this topic should be visited in the future rather than immediately punting. Who's keeping track of what things we need to track back on in the future? We should add virtualization to that list. > > > > > 3. Meta-comment: The model describes the existence of protocols > > between like layers (e.g. posture collector <--PA--> posture > > validator, posture broker client <--PB--> posture broker > > server), but provides no description as to what happens > > between different layers (posture collector <-> posture > > broker). I suspect that there's an unwritten assumption that > > different layers may communicate using APIs. If so, I > > suggest that at a minimum there be some suggestion on how > > different layers may be communicating (e.g. APIs) and noting > > that such work is out of scope for the current WG charter > > (and IETF in general). > > These were discussed during the formation of NEA and are out of scope. > We could add a sentence to state this in section 5 (or 3.1.) I'd rather > not make a statement whether they are API or protocol interfaces. In section 8.1.1 there's the statement, "The NEA Reference Model assumes all the NEA Client components are local to the Endpoint and communicate over local API or program calls." Doesn't this contradict you. > > Side note: Section 5.1.2.2 states that validators may be > > physically remote to the server. Doesn't this particular > > situation give rise to yet another > > protocol for the NEA model to denote? I can imagine the > > existence of a PV > > (Posture Validator) protocol between a remote posture > > validator and a posture broker server. Even though the > > current WG charter precludes working on any protocol other > > than PA and PB, we should nonetheless strive for completeness > > in the description of the model. > > This was discussed as well during the BOFs but was also removed from > the > final reference model presented by the chairs during the San Diego NEA > WG meeting and the model used prior to our approval to become a WG. > The current model only names the protocols we intend to specify > requirements for in this spec. With that said we did want to mention > that the Posture Validators could be remote in the text (as you noted) > because this might impact the security model and it helps understand > why > a deployer might wish to use strong security protections on the PA > Messages. Did you have a specific change in mind? Is it something we > can mention without defining and showing PV as a formal protocol (e.g. > extend some of the text in 5.1.2.[1,2]?) It sounds like a bit of a quagmire. If the model is untouchable, then the only option you have is to patch it with text in the sections you mention. BTW, were remote PV's considered during the development of the model? If so and they were left out intentionally, one could be dogmatic and say that remote PV's are prohibited (or at least out of scope) and your security mileage will vary with them present. > We had this discussion at the NEA WG meeting in San Diego when the > enforcement device was removed from the diagram (pre I-D). Their has > been a desire by folks in the WG to stay independent of the network > access layer. But by the same token you have section 8.1.2 describing them. > > > > 6. Section 5.1.1.1, last paragraph: From an interoperability > > perspective NEA should evaluate mandating a minimum amount of > > functionality > > so as to improve the odds of interoperable implementations. Or at a > > minimum there should be some form of signaling introduced > > into the protocol to provide for component capability advertisement. > > Is your point that the Posture Collector could support a fairly wide > variety of classes of Attributes and likely a variety of specific > Attributes so its difficult for a Posture Validator to know which ones > are supported? When we define the PA protocol, we should be able to Yes. But the opposite may also be true, whereby a posture collector supports a limited set of attributes. How does the posture validator know what the posture collector does or doesn't support? > address this issue. Is their a requirement you'd like to see added for > PA to enable this capability discovery or just add text to 5.1.1.1 to > describe the situation? Both. > > > > > 7. Section 5.1.1.2, first paragraph, second sentence: > > "...forwarding > > the request to the appropriate Posture Collectors." This > > sentence sounds like a request always goes to multiple > > collectors. I don't believe this is always the case, or is it? > > No its based upon which Posture Collectors are involved (requested to > be) in the assessment. Will clean-up the text to help. Ok. > > > > > 10. Section 5.1.2.1 mentions that a posture validator may > > be located on > > a separate server from the posture server. It goes on to say > > that the server may have to with both local and remote > > validators. One can assume that in the instance > > I can't parse this ... This was a test to see whether you checked every comment. You passed. Actually, it's a comment I failed to finish before sending the email. I can't remember what I was thinking about for this comment, but it may come back later. > > > > > 11. Section 5.1.2.2 describes as one of the roles being, > > "Communicating > > with remote Posture Validators and providing cryptographic > > protection for > > this communication." It's unclear to me what this exactly > > means. The > > broker server doesn't have any direct relationships with a > > posture validator, or does it? Furthermore, it's not clear > > The Posture Broker Server communicates (API or protocol) with the > Posture Validator(s) to pass PA Messages (and decisions.) > > > at what level the cryptographic protection is being provided. > > In section 5.1.1.3 (about posture transport client) it state > > clearly that its role is to protect the message dialog. I > > suggest the same level of clarity for server broker's role. > > Maybe this should be removed since this protocol is out of scope if its > confusing. We expected that their might be a security protocol between > the Posture Broker Server and Posture Validator. Within NEA scope, the > PA Messages could be encrypted/integrity protected end-to-end and flow > over this link but the Posture Broker Server doesn't have to do > anything > special for this to occur. I agree with removing it. It just detracts. > > > > > 12. Section 5.1.2.2 - Is it not the role of the posture > > broker server to > > also establish the overall compliance decision for an > > endpoint? Currently the document only assigns the generation > > of the global posture decision. If not the broker server, > > which component generates the overall compliance decision? > > Or is the global posture decision in fact the compliance > > decision? I'm confused. > > Global posture decision == overall compliance decision > > We don't use the expression "overall compliance decision" Ah, I see. > > 13. Section 5.1.2.3 - Why may there be more than one > > posture transport > > server in a particular NEA server? If there are truly > > multiple posture transport servers, then the NEA model > > diagram should be updated to reflect this possibility. See comment > #8. > > One for each transport/carrier protocol. You might imagine one for > IPsec, one for 802.1x, one for SSL, ... We will consider revising the > diagram. Ok. > > > > 15. Section 5.3.1 - I sense there is at some level some relationship > > between the attributes sent by a NEA server (i.e. requests) > > and those sent by a NEA client (i.e. responses). For > > example, isn't it the case that request attributes always and > > only elicit posture attributes as a response? > > Likewise, couldn't the same be said of policy attributes and > > compliance claim attributes? If so, it may be useful to > > highlight these relationships to make the protocol easier to > > understand. > > We'll work to make the relationships more clear. We did this already > for Compliance Claim and Policy Attributes but not Request and Posture > Attributes. Ok. > > > > > 16. Section 5.3.2 - It's unclear to me to what level the remediation > > attributes will get defined. On one hand the intro to this > > section (5.3) states that NEA WG will define a standard set > > of attributes. By the same token other parts of the document > > (e.g. section 3.1 - scope) state the > > standard protocols for remediation are out of scope. In defining > > remediation attributes are we not inadvertently defining a > > standard protocol for remediation? > > We decided to define the class of attributes so they can be a distinct > class (possibly becoming a separate name space) but we don't expect NEA > will define the specific attribute names/values due to our charter > limitation. It was handy to define the term for these attributes so we > could reference where they fit in the model/examples but that is all we > expected would be done with them. > The creation of the remediation attribute category but no standardizing within the category is an important point that should be highlighted in the document. Cheers, MS ------=_NextPart_000_0025_01C75EAF.0CC2CFD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMwNTA2NDcxMlowIwYJ KoZIhvcNAQkEMRYEFOWcXuWXV3FKhvhYbqYOAkhg114cMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgMonnFcx11WKc0ZRkdD1jQu8sRi8g40RULTCxRlIExPOUmCqZugCax6S0IQW+NDS y0RdTgtXO1so1j8z+gBfOij4fUTUDAyXSIBN06UmQ0WBvPrBjMVP39Aiu5ukSR7oVnSYLgBrJ/iM RLON/TFHt6n1c/ZWWA5M4ACFFyyzEFk5AAAAAAAA ------=_NextPart_000_0025_01C75EAF.0CC2CFD0-- --===============1227816961== 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 --===============1227816961==-- From nea-bounces@ietf.org Mon Mar 05 15:51:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK9g-0002Ar-BG; Mon, 05 Mar 2007 15:51:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK94-00016q-Nq; Mon, 05 Mar 2007 15:50:58 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOK8f-00007i-AA; Mon, 05 Mar 2007 15:50:58 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id EC3312ACC0; Mon, 5 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8A-0005ej-LS; Mon, 05 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: nea@ietf.org Subject: [Nea] I-D ACTION:draft-ietf-nea-requirements-01.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Endpoint Assessment Working Group of the IETF. Title : Requirements for Network Endpoint Assessment (NEA) Author(s) : P. Sangster, et al. Filename : draft-ietf-nea-requirements-01.txt Pages : 53 Date : 2007-3-5 This document defines the problem statement, scope and interface (protocol) requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g. an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance oriented decisions. The posture information is frequently useful for detecting systems that are lacking (or have out of date) security protective mechanisms (e.g. anti-virus, firewall). In order to provide context for the requirements, a reference model and terminology are introduced. This model is provided for informational purposes but is based on the models used by NAC [CNAC], NAP[NAP] and TNC[TNC]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nea-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nea-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-5115808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nea-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nea-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5115808.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From nea-bounces@ietf.org Mon Mar 05 17:01: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 1HOLEk-0004jS-1v; Mon, 05 Mar 2007 17:00:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLEi-0004jI-Vp for nea@ietf.org; Mon, 05 Mar 2007 17:00:52 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOLEg-0001jT-27 for nea@ietf.org; Mon, 05 Mar 2007 17:00:52 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 91AA738C26E; Mon, 5 Mar 2007 14:00:49 -0800 (PST) X-AuditID: d80ac287-a2231bb000002978-72-45ec93113fa3 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 4E17E348002; Mon, 5 Mar 2007 14:00:49 -0800 (PST) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HOLEf-0001Q9-5j; Mon, 05 Mar 2007 14:00:49 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Mar 2007 14:00:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: sections <= 2 Date: Mon, 5 Mar 2007 14:00:47 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A0268C095@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB211011CA0A9@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: sections <= 2 Thread-Index: AcdZTR2e0Qu1mxa1QhSnHu644vWgWwAyc7KQATM+p4AAIjsmwA== References: <2F2D38A4B8346F48A683750A46BAB2110113C552@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8DC0@SVL1XCHCLUPIN02.enterprise.veritas.com> <2F2D38A4B8346F48A683750A46BAB211011CA0A9@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 05 Mar 2007 22:00:48.0942 (UTC) FILETIME=[BBC324E0:01C75F71] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org =20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, March 04, 2007 9:41 PM > To: Paul Sangster; nea@ietf.org > Subject: RE: [Nea] REQ: sections <=3D 2 >=20 > Paul wrote... >=20 > > We wanted to call out when we were using a defined term vs. the=20 > > generic equivalent (roughly equivalent of SHOULD vs=20 > should.) Since we=20 > > use a few commonly used words (e.g. Message, Component ...) with a=20 > > special meaning we thought it was important to be clear what was=20 > > intended. For sections that are prior to the terminology=20 > section we=20 > > didn't wish to use defined terms (since they weren't=20 > defined yet) and=20 > > instead stick with generally known wordings. Another WG member=20 > > already pointed out that we missed a few terms that were=20 > used in the=20 > > abstract (which is fixed in -01.) >=20 > Perhaps the underlying issue here is not as much the=20 > capitalization (which is symptomatic of the issue), but the=20 > choice in terminology. Could better choice of terms assuage=20 > the need to capitalize?=20 I think the issue is the ability for the reader to easily identify which words that are defined terms (so reviewing the terminology section might help if a point is hard to understand.) The fact that we defined a few commonly used words as terms might add to people's confusion so we could discuss selecting other analogous terms if that helps. >=20 >=20 > > > > > > Section 2 specific comments > > > 1. How exactly do policy attributes differ from posture=20 > attributes? =20 > > > It's unclear to me because of the claim in the > >=20 > > Policy Attributes describe or reference policies that the Endpoint=20 > > must meet to be considered compliant ("must have firewall=20 > > running at least version 1.2.3"). These are sent by the NEA Server=20 > > (will add text to mention this.) > >=20 > > Posture Attributes includes Posture information about a requested=20 > > Component (Firewall installed, version 1.5, Firewall running, ...) =20 > > The Posture Validator compares this information to its policy to=20 > > determine compliance. These are sent by the NEA Client. >=20 > Ah...so if I this understand correct, policy attributes are=20 > used to carry just references to some [named] policy, while=20 > posture attributes are explicit posture values. To use a=20 Correct > programming analogy it's the case of pass by reference vs.=20 > pass by value.=20 Not sure the analogy is a perfect fit as call by reference means the data is provided via a reference rather than explicitly (on the stack). In this case the Policy information describes (possibly via reference) what the desired situation should be and the Posture information describes exactly what the current situation is. >=20 > If my understanding is correct, then I would suggest that the=20 > document describe the fact that policy attributes require the=20 > pre-population of policy in endpoint. Otherwise, the policy=20 I don't think we're requiring pre-population. The Policy Attributes might contain the policy or it might as you mention include keywords intending to locate the policy or it might have a more general reference to the policy (e.g. URI). We're not being overly precise as the WG will define the specific syntax/semantics of these attributes later but we did want to allow the policy to be encoded in the attributes or be available via reference (e.g. if they are large and/or the link is bandwidth constrained.) > attributes will likely reference policy that has no=20 > particular meaning to the endpoint. This also brings up the=20 > question of just how far we expect to standardize policy attributes. > While it may not be too difficult to reach consensus on=20 > attribute syntax, agreement on semantics, in particular how=20 > policy references should be interpreted, may be difficult. This is certainly something the WG will need to discuss. The notion of passing policy to the Endpoint and asking for its assessment of compliance is something that came up on the NEA alias so we wanted to accommodate that model but the WG should consider what level of specification is appropriate. =20 >=20 >=20 > > > definition of policy attributes that states that policy=20 > attributes=20 > > > can be used to establish compliancy without divulging posture=20 > > > information. Isn't the exchange of policy and compliance=20 > attributes=20 > > > in fact a form of posture information exchange. > >=20 > > I presume you mean Policy and Compliance Claim Attributes. In some=20 > > sense you could argue this but we felt it was important to be more=20 > > clear about the different types of attributes as they have=20 > differing=20 > > security, privacy and operational properties. We found these names=20 > > very helpful >=20 > I agree, but again I point out the statement, "...Policy=20 > Attributes might be used to enable an NEA client to determine=20 Note that it says "NEA Client" not "NEA Server". > whether the Endpoint is compliant without disclosing Posture=20 > information..." Don't you agree that policy and compliance=20 > claim attributes in fact do disclose indirectly posture=20 > information? I see where the design team is going with=20 > policy attributes, but probably went too far in asserting=20 > that posture attributes don't disclose [any] endpoint posture=20 > information.=20 They don't directly include posture information. I think you mean that a party might be able to infer some amount of posture information based on what policies/claims are also observed. Yes, some amount of inference is possible if a party can see both the policy information (actual policy rules) and the claim. How much information can be learned depends on the granularity of the policy (e.g. the policy might state 'you must run a firewall' and the compliance claim says 'yes, I'm running a firewall'). Not much is learned about the specific firewall (vendor, version, policies, ...) but sending posture attributes are likely to be more precise as it could state these exact values. We'll consider a reword of "without disclosing" in the definition to something more specific to inclusion within the attributes such as "without explicitly including" (we weren't intending to cover inference just what was included in the attribute values.) Does this help? >=20 > MS >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Mar 05 23:40:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HORSV-000592-6f; Mon, 05 Mar 2007 23:39:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HORST-00058x-Lr for nea@ietf.org; Mon, 05 Mar 2007 23:39:29 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HORSQ-0002xK-7a for nea@ietf.org; Mon, 05 Mar 2007 23:39:29 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id AEE1338C002; Mon, 5 Mar 2007 20:39:23 -0800 (PST) X-AuditID: d80ac287-a1830bb000002978-d8-45ecf07b4879 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 70B2B348002; Mon, 5 Mar 2007 20:39:23 -0800 (PST) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HORSN-0001CP-BD; Mon, 05 Mar 2007 20:39:23 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Mar 2007 20:39:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2007 20:39:22 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A0268C324@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB211011CA0BF@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Virtualization (Was part of: REQ: Section 5 comments) Thread-Index: AcdZTUcDOBr2jfMtQ6a6RDSRtgZTNAA58FdgAS3YlVAALxRcgA== References: <2F2D38A4B8346F48A683750A46BAB2110113C553@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8E2E@SVL1XCHCLUPIN02.enterprise.veritas.com> <2F2D38A4B8346F48A683750A46BAB211011CA0BF@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 06 Mar 2007 04:39:23.0122 (UTC) FILETIME=[69B96D20:01C75FA9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Nea] Virtualization (Was part of: REQ: Section 5 comments) X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Comments below...=20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, March 04, 2007 10:47 PM > To: Paul Sangster; nea@ietf.org > Subject: RE: [Nea] REQ: Section 5 comments >=20 >=20 > Paul wrote... >=20 > >=20 > > Which virtualization model are you concerned about? Is it=20 > hypervisor=20 > > style (multi guest OSes and/or virtual appliances) as per a=20 > Xen model? > > If so, why couldn't the NEA Client just run in each guest OS and=20 > > provide Posture like it would in a non-virtualized environment? If=20 > > multiple guest OSes exist, each normally have their own network=20 > > interfaces (possibly [para]virtualized) but they could report their=20 > > Posture when requested on their interface (or when attempting to=20 > > connect to the > > network.) The primary difference I see is the potential lack of=20 > > Posture about the hypervisor layer but this could be addressed in=20 > > different ways. > > This might be an interesting dialog to have on the alias to=20 > determine=20 > > if we need to push this out of scope or whether this is=20 > similar enough=20 > > to our model that it could remain in scope and be discussed. >=20 > So it sounds like you're of the mindset that this topic=20 > should be visited in the future rather than immediately=20 > punting. Who's keeping track of what things we need to track=20 > back on in the future? We should add virtualization to that list.=20 Now that -01 is published it's a fine time to discuss this topic so this topic has been separated from the prior thread in hopes of giving it more attention from the WG. Can you explain more about the virtualization model you had in mind and how it might impact the spec? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Mar 06 00:04:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HORqN-0002un-5R; Tue, 06 Mar 2007 00:04:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HORqM-0002ui-3m for nea@ietf.org; Tue, 06 Mar 2007 00:04:10 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HORqL-0004wb-G0 for nea@ietf.org; Tue, 06 Mar 2007 00:04:10 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 135C238C0A0; Mon, 5 Mar 2007 21:04:09 -0800 (PST) X-AuditID: d80ac287-9e19abb000002978-4f-45ecf6487fb1 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id BF77E348002; Mon, 5 Mar 2007 21:04:08 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HORqK-0002Dl-Kq; Mon, 05 Mar 2007 21:04:08 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 21:04:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: Section 5 comments Date: Mon, 5 Mar 2007 21:04:06 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A0268C329@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB211011CA0BF@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 5 comments Thread-Index: AcdZTUcDOBr2jfMtQ6a6RDSRtgZTNAA58FdgAS3YlVAAL0Kw0A== References: <2F2D38A4B8346F48A683750A46BAB2110113C553@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8E2E@SVL1XCHCLUPIN02.enterprise.veritas.com> <2F2D38A4B8346F48A683750A46BAB211011CA0BF@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 06 Mar 2007 05:04:08.0493 (UTC) FILETIME=[DF130DD0:01C75FAC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Comments below... > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, March 04, 2007 10:47 PM > To: Paul Sangster; nea@ietf.org > Subject: RE: [Nea] REQ: Section 5 comments >=20 >=20 > Paul wrote... >=20 > >=20 > > > > > > 3. Meta-comment: The model describes the=20 > existence of protocols > > > between like layers (e.g. posture collector <--PA--> posture=20 > > > validator, posture broker client <--PB--> posture broker server),=20 > > > but provides no description as to what happens between different=20 > > > layers (posture collector <-> posture broker). I suspect that=20 > > > there's an unwritten assumption that different layers may=20 > > > communicate using APIs. If so, I suggest that at a=20 > minimum there be=20 > > > some suggestion on how different layers may be=20 > communicating (e.g.=20 > > > APIs) and noting that such work is out of scope for the=20 > current WG=20 > > > charter (and IETF in general). > >=20 > > These were discussed during the formation of NEA and are=20 > out of scope. > > We could add a sentence to state this in section 5 (or 3.1.) I'd=20 > > rather not make a statement whether they are API or=20 > protocol interfaces. >=20 > In section 8.1.1 there's the statement, "The NEA Reference=20 > Model assumes all the NEA Client components are local to the=20 > Endpoint and communicate over local API or program calls." =20 > Doesn't this contradict you.=20 Apparently so :). We'll consider removing the "and communicate ..." phrase. *If* we're going to add the text you suggest it should probably be in the Reference Model section. >=20 > > > Side note: Section 5.1.2.2 states that validators may be=20 > physically=20 > > > remote to the server. Doesn't this particular situation=20 > give rise=20 > > > to yet another > > > protocol for the NEA model to denote? I can imagine the > > > existence of a PV > > > (Posture Validator) protocol between a remote posture=20 > validator and=20 > > > a posture broker server. Even though the current WG charter=20 > > > precludes working on any protocol other than PA and PB, we should=20 > > > nonetheless strive for completeness in the description of=20 > the model. > >=20 > > This was discussed as well during the BOFs but was also=20 > removed from=20 > > the final reference model presented by the chairs during=20 > the San Diego=20 > > NEA WG meeting and the model used prior to our approval to become a=20 > > WG. > > The current model only names the protocols we intend to specify=20 > > requirements for in this spec. With that said we did want=20 > to mention=20 > > that the Posture Validators could be remote in the text (as=20 > you noted)=20 > > because this might impact the security model and it helps=20 > understand=20 > > why a deployer might wish to use strong security=20 > protections on the PA=20 > > Messages. Did you have a specific change in mind? Is it=20 > something we=20 > > can mention without defining and showing PV as a formal=20 > protocol (e.g. > > extend some of the text in 5.1.2.[1,2]?) >=20 > It sounds like a bit of a quagmire. If the model is=20 > untouchable, then the only option you have is to patch it=20 > with text in the sections you mention. =20 >=20 > BTW, were remote PV's considered during the development of=20 > the model? If so and they were left out intentionally, one=20 > could be dogmatic and say that remote PV's are prohibited (or=20 > at least out of scope) and your security mileage will vary=20 > with them present.=20 Yes their was a lot of discussion about the PV protocol during the early days of NEA but it was deemed out of scope. This might be something to consider addressing after the WG meets all our chartered set of milestones. Depending on how the WG feels about the remote PV topic we might remove all mentions of it from the draft (or if the chair's want to declare it in scope ...) >=20 > > We had this discussion at the NEA WG meeting in San Diego when the=20 > > enforcement device was removed from the diagram (pre I-D). =20 > Their has=20 > > been a desire by folks in the WG to stay independent of the network=20 > > access layer. >=20 > But by the same token you have section 8.1.2 describing them.=20 What is out of scope is the NEA protocols to/from the enforcement devices. This section merely discusses that network devices could impact the security of the NEA protocols so should be considered. >=20 >=20 > > > > > > 6. Section 5.1.1.1, last paragraph: From an=20 > interoperability > > > perspective NEA should evaluate mandating a minimum amount of=20 > > > functionality > > > so as to improve the odds of interoperable=20 > implementations. Or at a > > > minimum there should be some form of signaling introduced=20 > into the=20 > > > protocol to provide for component capability advertisement. > >=20 > > Is your point that the Posture Collector could support a=20 > fairly wide=20 > > variety of classes of Attributes and likely a variety of specific=20 > > Attributes so its difficult for a Posture Validator to know=20 > which ones=20 > > are supported? When we define the PA protocol, we should be able to >=20 > Yes. But the opposite may also be true, whereby a posture=20 > collector supports a limited set of attributes. How does the=20 > posture validator know what the posture collector does or=20 > doesn't support? I'd be interested in hearing other folks opinion on this as I think this reasoning makes sense. However, I've heard the argument that their will be a core (standard) set of Attributes that MUST be supported so this is really more towards the vendor specific where Attributes might not be supported (and thus potentially not interesting to define). This argument implies that we won't have any Attributes that are syntactically defined yet are a MAY or SHOULD to implement (I could envision this happening for some attributes that support a particular usage model like the Compliance Claim Attributes). =20 >=20 > > address this issue. Is their a requirement you'd like to see added=20 > > for PA to enable this capability discovery or just add text=20 > to 5.1.1.1=20 > > to describe the situation? >=20 > Both. Ok, this warrents a discussion. >=20 > >=20 > > > > > > 16. Section 5.3.2 - It's unclear to me to what=20 > level the remediation > > > attributes will get defined. On one hand the intro to=20 > this section=20 > > > (5.3) states that NEA WG will define a standard set of=20 > attributes. =20 > > > By the same token other parts of the document (e.g. section 3.1 -=20 > > > scope) state the > > > standard protocols for remediation are out of scope. In defining > > > remediation attributes are we not inadvertently defining=20 > a standard=20 > > > protocol for remediation? > >=20 > > We decided to define the class of attributes so they can be=20 > a distinct=20 > > class (possibly becoming a separate name space) but we don't expect=20 > > NEA will define the specific attribute names/values due to=20 > our charter=20 > > limitation. It was handy to define the term for these=20 > attributes so=20 > > we could reference where they fit in the model/examples but that is=20 > > all we expected would be done with them. > > >=20 > The creation of the remediation attribute category but no=20 > standardizing within the category is an important point that=20 > should be highlighted in the document.=20 Ok, we'll look to add alittle text on this. >=20 > Cheers, > MS >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Mar 06 00:11:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HORxA-0005BX-A4; Tue, 06 Mar 2007 00:11:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HORx8-0005As-QT for nea@ietf.org; Tue, 06 Mar 2007 00:11:10 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HORx7-0005ah-5C for nea@ietf.org; Tue, 06 Mar 2007 00:11:10 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id A42C738C002; Mon, 5 Mar 2007 21:11:08 -0800 (PST) X-AuditID: d80ac287-a1830bb000002978-7b-45ecf7ec0a8a Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 5BCAB348002; Mon, 5 Mar 2007 21:11:08 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HORx6-0001QU-8a; Mon, 05 Mar 2007 21:11:08 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 21:11:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: section 8 Date: Mon, 5 Mar 2007 21:11:07 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A0268C32B@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB211011CA0B7@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: section 8 Thread-Index: AcdZTZ9vKINEVuojQAC6aQZLQy8vJAA1bpLAATHlDeAAMKAgsA== References: <2F2D38A4B8346F48A683750A46BAB2110113C556@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8DE5@SVL1XCHCLUPIN02.enterprise.veritas.com> <2F2D38A4B8346F48A683750A46BAB211011CA0B7@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 06 Mar 2007 05:11:08.0037 (UTC) FILETIME=[D9246350:01C75FAD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Comments below ...=20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, March 04, 2007 10:02 PM > To: Paul Sangster; nea@ietf.org > Subject: RE: [Nea] REQ: section 8 >=20 > > > > > > My comments on section 8: > > > 1. Section 8.1, ".NEA client frequently is expected to trust the=20 > > > network infrastructure not to misuse any disclosed Posture=20 > > > information." sentence: > > > Doesn't the client always need to trust that the network=20 > > > infrastructure isn't going to misuse the posture information? > > > What are some examples where it doesn't need to trust the=20 > > > infrastructure? > >=20 > > We could make this absolute but their could be situations where the=20 > > client didn't disclose any sensitive information that it=20 > cares about=20 > > being disclosed to other parties (e.g. when it sends only=20 > Compliance=20 > > Claim Attributes.) Another option might be that the employment=20 > > agreement the Endpoint User signed states that the Endpoint=20 > Owner (who=20 > > is also the network Owner) can make use of the information=20 > in any way=20 > > it sees fit. In general, I agree with your comment but wanted to=20 > > leave the door open for (hopefully!) less common=20 > situations. Maybe we=20 > > should change "frequently" to "normally"? >=20 > I support the word change to clarify the sentence.=20 Included in -01 >=20 >=20 > > > 2. Section 8.1.3 - Isn't there a version of the "lying client"=20 > > > problem that is applicable to servers? What if my NEA=20 > server were=20 > > > compromised in a way that it no longer could be trusted=20 > to function=20 > > > correctly? I'd say each server component needs the same=20 > protection=20 > > > afforded to clients for the lying client problem. > >=20 > > Can you explain more? In these examples the server isn't being=20 > > assessed by the client. If it were being assessed, then=20 > this would be=20 > > an issue. > > What did you have in mind (is it the server being=20 > assessed)? In this=20 > > case the NEA Server would run on the Endpoint and the NEA Client on=20 > > the "server". >=20 > A NEA client doesn't assess the NEA server from a posture=20 > compliance perspective, but doesn't the NEA client need to=20 > minimally establish that it's speaking to a valid NEA server? =20 Done through authentication. >=20 > If I were running a NEA client on my laptop I wouldn't reply=20 > to requests from just any arbitrary NEA server. I'd first=20 > want to make sure that I was talking to a valid NEA server=20 > before handing over my posture info. =20 Their would be a strong authentication so you'd know the identity of the NEA Server before disclosing any information to it. >=20 >=20 > Cheers, > MS >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Mar 06 00:17:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOS2d-0000Jy-Nq; Tue, 06 Mar 2007 00:16:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOS2c-0000GN-Ih for nea@ietf.org; Tue, 06 Mar 2007 00:16:50 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOS2b-00060L-2U for nea@ietf.org; Tue, 06 Mar 2007 00:16:50 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id A0BB338C07E; Mon, 5 Mar 2007 21:16:48 -0800 (PST) X-AuditID: d80ac287-9eb9bbb000002978-32-45ecf940000b Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 5DBEF348002; Mon, 5 Mar 2007 21:16:48 -0800 (PST) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HOS2a-0002qV-7x; Mon, 05 Mar 2007 21:16:48 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Mar 2007 21:16:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: section 6 comments Date: Mon, 5 Mar 2007 21:16:47 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A0268C32D@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <2F2D38A4B8346F48A683750A46BAB211011CA0B4@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: section 6 comments Thread-Index: AcdZTWwbN5FEzEn9QOG++FfOr+9CqQAz4axAATMGfTAAMTlzYA== References: <2F2D38A4B8346F48A683750A46BAB2110113C554@G3W0072.americas.hpqcorp.net> <5A58F967CBEBBB4A82DF126CF8A9596A025A8DDD@SVL1XCHCLUPIN02.enterprise.veritas.com> <2F2D38A4B8346F48A683750A46BAB211011CA0B4@G3W0072.americas.hpqcorp.net> From: "Paul Sangster" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 06 Mar 2007 05:16:48.0060 (UTC) FILETIME=[A3CFC7C0:01C75FAE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Comments below...=20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, March 04, 2007 9:55 PM > To: Paul Sangster; nea@ietf.org > Subject: RE: [Nea] REQ: section 6 comments >=20 > Paul wrote... >=20 > >=20 > > One of the goals of the spec was to broadly describe the=20 > problem space=20 > > in the use case (examples.) We carefully allocated=20 > different aspects=20 > > of the problem space to each of the 5 use case areas. We=20 > recognized=20 > > that the 1st use case was pretty complex (but is likely a well=20 > > understood > > scenario) so you'll note step 14 doesn't go into the re-assessment=20 > > details. If we separated out the remediation it wouldn't make this=20 > > much simpler (removes steps 14-16 only.) >=20 > Given that re-assessment appears to be covered by other use=20 > case examples, the design team may want to consider stripping=20 > out 14-16 out. As you point out, the use case is already=20 > complex as it is.=20 We'll discuss this. >=20 >=20 > > > 2. Section 6.1.1.2 - I don't believe step 14 is true. > > > After the OS > > > Patch validator signals success it's highly unlikely the=20 > user will=20 > > > physically re-connect to the network to get a=20 > re-assessment started. =20 > > > I suspect the NEA components have some facility to request global=20 > > > re-assessment, right? > >=20 > > Correct, we'll try to fix the wording. Note however that step 1=20 > > doesn't mention booting or user interaction just that: "The IT=20 > > employee's desktop computer connects to the network...". =20 > If it helps=20 > > we could address this comment. >=20 > Ok. I await the new wording.=20 Its in -01 >=20 >=20 > > > 3. Section 6.1.1.3 - Not sure what this section is trying > > > to say. This > > > section does highlight some characteristics of the=20 > example scenario,=20 > > > but I don't see how this translates into impact on requirements. =20 > > > Consider adding additional discussion to clarify. > >=20 > > Ok. These are "different aspects of the problem space" mentioned=20 > > above that could impact the requirement definitions. Some text to=20 > > explain this would be helpful. >=20 > Agree. >=20 > >=20 > > > > > > 4. Section 6.1.2 - What is meant by network=20 > service? Isn't the > > > scenario described by section 6.1.1 essentially also an=20 > example of a=20 > > > request for a network service? Please compare/contrast somewhere=20 > > > initial network connect and request for network service. > >=20 > > I presume the example given in 6.1.2 wasn't sufficent (detailed=20 > > enough)? > > One could imagine this being a request to a protected=20 > service like the=20 > > Financial Portal server which contains very sensitive and mission=20 > > critical data. We used the example of VPN to show an L3 (instead of > > L7) > > service request but as you mention this smells similar to the L2=20 > > initial network connect example. We could switch it if others feel=20 > > this is important. >=20 > Having clearly differentiated use cases and adjoining=20 > examples is extremely desirable. =20 >=20 >=20 > > > 5. Section 6.1.2.1 - This example triggered in my mind a > > > new derivative > > > use case. Namely, what about a use case that involves=20 > the need to=20 > > > pass multiple [concurrent] assessments? For example,=20 > what if I'm a=20 > > > guest at a company that provides guest LAN network=20 > connectivity as=20 > > > long as I pass muster via NEA. What if then I desire to connect=20 > > > back via VPN to my company's network that also requires passing=20 > > > security muster via NEA. > > > This seems like a realistic and probable use case. Would NEA=20 > > > protocols support this? > >=20 > > Certainly more complicated and I'm not sure this introduces=20 > an aspect=20 > > of the problem space that we didn't already cover. I presume this=20 > > would just be 2 independent assessments without knowledge of each=20 > > other (?). >=20 > Hypothetically speaking, if on describes use case A and use=20 > case B, does this mean that use case A+B is automatically=20 > supported? I would say that it's not automatic in most=20 > cases. You make the valid point that in the (A+B) case that I=20 > postulate there's a need to have 2 independent assessments=20 > with knowledge of each other. In which of the existing use=20 > cases does this requirement get covered? Not sure it's a requirements specific to PA, PB or PT. This seems like a property of the architecture and an implementation. >=20 > Cheers, > MS >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Mar 06 11:00: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 1HOc59-0001Ew-DC; Tue, 06 Mar 2007 11:00:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOc57-0001DS-Oa for nea@ietf.org; Tue, 06 Mar 2007 11:00:05 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOc55-0002Dl-Er for nea@ietf.org; Tue, 06 Mar 2007 11:00:05 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l26G026Q018231 for ; Tue, 6 Mar 2007 11:00:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Mar 2007 09:00:02 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Remote Posture Validators Thread-Index: AcdgCH8fRq7SgjxdQiKfMh2FgA9sHQ== From: "Mani, Mahalingam \(Mani\)" To: "nea" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Subject: [Nea] Remote Posture Validators 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="===============1803795215==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1803795215== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76008.7FC41430" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76008.7FC41430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On the topic of whether Posture Validators need to be collocated to the Posture Broker Server (PBS) in the NEA Server In the -00 and -01 drafts (5.1.2) it is stated that the Posture Validator (PV) to be located on another server than the PBS requiring the PBS to deal with local and remote PVs. =20 In writing this section we had discussed at length the pros and cons of supporting remote PVs on whether this should be a requirement going forward. =20 While remote PVs provide the flexibility of running on independent platforms (or on related servers if any), they carry the additional burden of establishing a trust relationship with the PBS(s) and also the question of standardizing PBS<->PV transport; among other considerations. =20 We would like to get the WG's thoughts on this. =20 Regards, -mani ------_=_NextPart_001_01C76008.7FC41430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On the topic of whether Posture Validators need to be = collocated to the Posture Broker Server (PBS) in the NEA = Server

In the -00 and -01 drafts (5.1.2) it is stated that = the Posture Validator (PV) to be located on another server than the = PBS

requiring the PBS to deal with local and remote = PVs.

 

In writing this section we had discussed at length = the pros and cons of supporting remote PVs on whether this should be a = requirement going forward.

 

While remote PVs provide the flexibility of running = on independent platforms (or on related servers if any), they carry the additional = burden of establishing a trust relationship with the PBS(s) and also the question = of standardizing PBS<->PV transport; among other = considerations.

 

We would like to get the WG’s thoughts on = this.

 

Regards,

-mani

------_=_NextPart_001_01C76008.7FC41430-- --===============1803795215== 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 --===============1803795215==-- From nea-bounces@ietf.org Tue Mar 06 11:32: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 1HOcaf-0008Rr-PA; Tue, 06 Mar 2007 11:32:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOcad-0008Qk-PQ for nea@ietf.org; Tue, 06 Mar 2007 11:32:39 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOcaa-0007q8-32 for nea@ietf.org; Tue, 06 Mar 2007 11:32:39 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id A271038C495 for ; Tue, 6 Mar 2007 08:32:35 -0800 (PST) X-AuditID: d80ac287-a2c32bb000002978-c6-45ed97a3aef0 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 70B52348004 for ; Tue, 6 Mar 2007 08:32:35 -0800 (PST) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HOcaZ-0001g0-Bf for nea@ietf.org; Tue, 06 Mar 2007 08:32:35 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Mar 2007 08:32:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Remote Posture Validators Date: Tue, 6 Mar 2007 08:32:17 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A0268C4DF@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Remote Posture Validators Thread-Index: AcdgCH8fRq7SgjxdQiKfMh2FgA9sHQAA7Mag References: From: "Paul Sangster" To: "nea" X-OriginalArrivalTime: 06 Mar 2007 16:32:16.0712 (UTC) FILETIME=[00C54C80:01C7600D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 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="===============0575321730==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0575321730== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7600D.00ADA5D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7600D.00ADA5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to be clear on the question, because we are not chartered to define requirements (nor select) a remote PV protocol, would the WG prefer: =20 1) We not mention remote validators in the spec 2) We acknowledge their existance largely for discussing their impact on the architecture, considerations (security, privacy and other) similar to our current coverage 3) Increase the discussion of remote validators in some way (explain how) =20 Paul ________________________________ From: Mani, Mahalingam (Mani) [mailto:mmani@avaya.com]=20 Sent: Tuesday, March 06, 2007 8:00 AM To: nea Subject: [Nea] Remote Posture Validators =09 =09 On the topic of whether Posture Validators need to be collocated to the Posture Broker Server (PBS) in the NEA Server In the -00 and -01 drafts (5.1.2) it is stated that the Posture Validator (PV) to be located on another server than the PBS requiring the PBS to deal with local and remote PVs. =20 In writing this section we had discussed at length the pros and cons of supporting remote PVs on whether this should be a requirement going forward. =20 While remote PVs provide the flexibility of running on independent platforms (or on related servers if any), they carry the additional burden of establishing a trust relationship with the PBS(s) and also the question of standardizing PBS<->PV transport; among other considerations. =20 We would like to get the WG's thoughts on this. =20 Regards, -mani ------_=_NextPart_001_01C7600D.00ADA5D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just to be clear on the question, because we = are not=20 chartered to define requirements (nor select) a remote PV protocol, = would the WG=20 prefer:
 
1) We not mention remote validators in the=20 spec
2) We acknowledge their existance largely for = discussing=20 their impact on the architecture, considerations (security, privacy and = other)=20 similar to our current coverage
3) Increase the discussion of remote validators = in some way=20 (explain how)
 
Paul

From: Mani, Mahalingam (Mani)=20 [mailto:mmani@avaya.com]
Sent: Tuesday, March 06, 2007 8:00 = AM
To: nea
Subject: [Nea] Remote Posture=20 Validators

On the topic of whether = Posture=20 Validators need to be collocated to the Posture Broker Server (PBS) in = the NEA=20 Server

In the -00 and -01 = drafts (5.1.2)=20 it is stated that the Posture Validator (PV) to be located on another = server=20 than the PBS

requiring the PBS to = deal with=20 local and remote PVs.

 

In writing this section = we had=20 discussed at length the pros and cons of supporting remote PVs on = whether this=20 should be a requirement going forward.

 

While remote PVs provide = the=20 flexibility of running on independent platforms (or on related servers = if=20 any), they carry the additional burden of establishing a trust = relationship=20 with the PBS(s) and also the question of standardizing PBS<->PV=20 transport; among other considerations.

 

We would like to get the = WG’s=20 thoughts on this.

 

Regards,

-mani

------_=_NextPart_001_01C7600D.00ADA5D0-- --===============0575321730== 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 --===============0575321730==-- From nea-bounces@ietf.org Wed Mar 07 18:25:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5Vi-0007C3-9s; Wed, 07 Mar 2007 18:25:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP52Y-0005FO-CK for nea@ietf.org; Wed, 07 Mar 2007 17:55:22 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP4Hj-0003a6-Ol for nea@ietf.org; Wed, 07 Mar 2007 17:07:01 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 07 Mar 2007 14:07:00 -0800 X-IronPort-AV: i="4.14,261,1170662400"; d="scan'208"; a="687064224:sNHT37438568" 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, 7 Mar 2007 17:06:57 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft agenda for IETF 68 NEA WG meeting Thread-Index: AcdhBOwIWMv9ithRTVi+hwXcbBFfFw== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Nea] Draft agenda for IETF 68 NEA WG meeting 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 is a draft agenda for the NEA WG meeting at IETF 68. Most of our time will be spent working through issues related to the NEA Requirements draft. We will also talk about tweaking our milestones and learn about issues that FWNA and eduroam raise relating to NEA. If you want to request changes to this draft agenda, please let me know. Thanks, Steve ------- Agenda for IETF 68 NEA WG Meeting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Date: Tuesday, March 20, 2007 Time: 1300-1500 CET (GMT+0100) Place: Hilton Prague, Congress I WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org WG Chairs: Steve Hanna , Susan Thomson Agenda Version: 1 1300 Administrivia Agenda Bashing Scribes Blue Sheets 1305 WG Status 1310 Discuss Proposed Milestone Revisions 1325 Discuss NEA Requirements Draft =20 http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-01.txt 1440 FWNA, Eduroam, and NEA 1455 Review of Next Steps 1500 Adjourn _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Mar 09 04:19:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbFj-0004Ue-HV; Fri, 09 Mar 2007 04:19:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPg3-0005Bv-Es for nea@ietf.org; Thu, 08 Mar 2007 15:57:34 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPfP-0000r1-OR for nea@ietf.org; Thu, 08 Mar 2007 15:57:27 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Mar 2007 15:56:52 -0500 X-IronPort-AV: i="4.14,264,1170651600"; d="scan'208"; a="54340143:sNHT825258294" 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 l28Kupfd017108; Thu, 8 Mar 2007 15:56:51 -0500 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 l28KuCaN018307; Thu, 8 Mar 2007 20:56:51 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); Thu, 8 Mar 2007 15:56:31 -0500 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: Thu, 8 Mar 2007 15:56:39 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to charter milestone dates Thread-Index: AcdhxER4yhd8qVDgSYaHbWxPu0KZsw== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 08 Mar 2007 20:56:31.0035 (UTC) FILETIME=[3F8280B0:01C761C4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1026; t=1173387411; x=1174251411; 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:=20Updates=20to=20charter=20milestone=20dates |Sender:=20 |To:=20; bh=NBt2m2AWrDTKiIM47gGucExhVkHlFXVLlbFpaXxZLYU=; b=ZjT5LJHo/o9+vSTTwkJrhfMqciXdM3pUvOMSs4QnfqogeoyEv8T0BTaD5BHkXboSxBHVF1fB m99MdcuqUcRDur6ZCe3KJgp5zO6ZBQI6DkDYFqedBZ2eDbjhslUHfzHJ; 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 Cc: Subject: [Nea] Updates to charter milestone dates 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 Folks We need to update the milestones in the charter. (The original milestones were out-of-date by the time the WG was chartered.) Below are the proposed new dates. Any issues, let us know. To meet these milestones, we will need to step up the pace of comments on the requirements draft over the next couple of months. We encourage those in the working group who have not provided feedback yet to review the draft as soon as possible.=20 Thanks Susan & Steve Done At IETF 67, discuss NEA Requirements=20 Done Submit first draft of NEA Requirements I-D=20 Done Submit revised NEA requirements I-D=20 Mar 2007 At IETF 68, resolve open issues with requirements I-D =20 Apr 2007 Submit revised NEA requirements I-D May 2007 WGLC on NEA Requirements I-D Jun 2007 Submit revised NEA requirements I-D based on WGLC comments Jul 2007 At IETF 69, resolve any remaining issues raised at Last Call Aug 2007 Submit NEA Requirements I-D to the IESG for IETF Last Call as Informational RFC _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Mar 18 13:05: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 1HSyoa-0006Nl-RY; Sun, 18 Mar 2007 13:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSvwg-0007gu-21 for nea@ietf.org; Sun, 18 Mar 2007 10:01:14 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSvtO-0005rD-Dy for nea@ietf.org; Sun, 18 Mar 2007 09:57:55 -0400 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id D184E38C01D; Sun, 18 Mar 2007 06:57:49 -0700 (PDT) X-AuditID: d80ac287-9edd6bb000000de9-3f-45fd455d2a56 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 42CC7348002; Sun, 18 Mar 2007 06:57:49 -0700 (PDT) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HSvtN-0006Al-0t; Sun, 18 Mar 2007 06:57:49 -0700 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 18 Mar 2007 06:57:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] NEA requirements draft comments Date: Sun, 18 Mar 2007 06:56:49 -0700 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A027ABBDF@SVL1XCHCLUPIN02.enterprise.veritas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] NEA requirements draft comments Thread-Index: Acda14+CQJ98/aPZQoOxWaafDVKDZAAjhq8AA3/XzZA= References: <08A9A3213527A6428774900A80DBD8D8038EFCB7@xmb-sjc-222.amer.cisco.com> From: "Paul Sangster" To: "nea" X-OriginalArrivalTime: 18 Mar 2007 13:57:48.0782 (UTC) FILETIME=[699C68E0:01C76965] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: b0cb28733abb902a8fbcef7211f5fadf X-Mailman-Approved-At: Sun, 18 Mar 2007 13:05:03 -0400 Cc: "Nancy Winget \(ncamwing\)" 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="===============1691992226==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1691992226== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76965.6942BEC6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76965.6942BEC6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just realized my 3/5 response to Nancy's comments didn't also go to the alias. ________________________________ From: Paul Sangster=20 Sent: Monday, March 05, 2007 8:25 PM To: 'Nancy Winget (ncamwing)' Subject: RE: [Nea] NEA requirements draft comments =09 =09 Thanks for your comments, many of the responses below were included in the (now published) -01 I-D (just didn't have time to send out the response). Comments with [PS] prefix... =09 ________________________________ From: Nancy Winget (ncamwing) [mailto:ncamwing@cisco.com]=20 Sent: Tuesday, February 27, 2007 5:27 PM To: nea@ietf.org Subject: [Nea] NEA requirements draft comments =09 =09 Hi, =20 I reviewed the requirements and security considerations of the NEA requirements draft and have some comments below: =20 =09 General: - the terms Client and NEA Client, are used interchangeably; only one term should be chosen and used consistantly. Similary for Server and NEA Server. =20 [PS] Reviewed the draft and fixed these ambiguities (however left uses of "NEA Client and Server" which seems clear enough. Some uses of "server" were also appropriate. Didn't find any examples of "Client" or "Server" (capitalized) without a NEA oriented prefix. =20 Section 2. Terminology - Should add the following terms as they are used throughout the draft: Validator (or Posture Validator and use only one of these terms), NEA Client, NEA Server, NEA Component =20 [PS] These are described in the Reference Model section. We felt these needed more context then a short definition. =20 - consider adding one or two terms for: User, Owner, Deployer, Administrator =20 [PS] Added "User" which we had intended to define all along and Deployer. Owner was already defined. Will consider adding others as well although some have expressed a concern about our defining terms for too many generic (well known) words. User and Owner were important for the privacy considerations section so were desired. =20 - Policy: there is much mention of the general term "policy" which at times is a configuration option, at times a set of "Policy Attributes" and at times something else, that needs to be clarified and defined in this section. =20 [PS] Policy Attributes are defined. Not sure if we want to try to define something specific for the term policy but am open to feedback on this (including text contributions.)=20 =20 Section 7.1 Common Protocol Requirements =20 [PS] We will discuss section 7 at a later date as our current focus is on the context setting sections. We appreciate the comments and will respond to these separately.=20 =20 - the protocol requirements put forth imply that there is a predefined means by which the client and server know how to reach each other. This could be implied or also assumed by the underlying protocol, but is not mentioned in either the requirements, assumptions or considerations sections. While there is mention to this in the architecture section, there should be more clear mention as to such assumptions in either Section 7 or Section 8 as well. - while the individual requirements for the PA, PB and PT protocols call out for confidentiality and integrity, the common section does not. While C-4 speaks to protection against active, passive and replay attacks, there is no mention to forgery or eavesdropping attacks? =20 =20 Section 7.4 Posture Transport (PT) Protocol Requirements - Should PT-5 also include retransmissions? =20 Section 8.1 Trust - This paragraph is too leading and can be construed to attempt to impose further security requirements versus a descriptive statement to assert that the trustworthiness of the attribute contents is beyond the scope of this body. Further the security requirements imposed on the PA, PB and PT are to establish trust between the NEA Client and NEA Server but does not assert trust of the Endpoint hosting the NEA Client. My suggestion is to reword the first paragraph of this section to something like: "Network Endpoint Assement enables NEA Clients and NEA Servers to communicate Posture information that is assessed by Posture Validators. The trust relationship established between the NEA Client and NEA Server is used to securely exchange attributes but is not intended to provide assuranses to the trustworthiness of the Endpoint." =20 [PS] Based on others prior comments the initial sentence was replaced with something closer to what you have suggested.=20 =20 Section 8.1.1 Client Components - 1st sentence of the first paragraph should read: "For NEA to properly operate, the NEA Client component of the Endpoint needs to be trusted to accurately represent the requested security Posture of the Endpoint to the NEA Server." =20 [PS] The intention was to be more broad as their could be other software on the Endpoint that might trick the NEA Client into misrepresenting the Posture of the system. We are trusting that this is not happening and that the Endpoint is accurately representing its Posture. =20 - it is not clear to me why the rest of this first paragraph (e.g. 2nd sentence to end of paragraph) is needed? If the point is "The trustworthiness of the contextual information of the attributes themselves is beyond the scope of this draft." then it should just state that and removed the rest of the text. =20 [PS] This text is consistent with the NEA WG charter ("However, the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints.") and is one of the items that needs to be covered by our activities. This was discussed at the NEA BOFs. Unless its not accurate or misleading i would prefer to see it remain. What is the concern about this text?=20 =20 - The 2nd paragraph should also include that there must be some inherent trust between the NEA Server with the NEA Client that is doing the comparison and effective compliance validation. =20 [PS] Can you be more specific? If I understand the comment this is at the heart of what this paragraph is about. I made one change (c/we/the NEA Server/) to help clarity but this might not have captured your intent. =20 - The 3rd paragraph should define what is meant by "User or Owner" policy. I assume it is policy configured at the Endpoint based on a particular User identity? =20 [PS] Its policy defined by the User and/or Owner of the Endpoint as being authorized for use of the Endpoint (e.g. firewall rules.) The details of the policy are mechanism specific. Changed to "User or Owner defined policy." =20 Section 8.1.2 Network Communications - The last paragraph of this section states a rationale for requiring confidentiality, integrity and replay protection and should be transcribed as such. It currently reads as being too passive, where the requirements posted in Section 7 impose some of these protections as a MUST. My suggestion is to state that NEA must guard against such attacks by providing confidentiality, integrity and replay protection minimally (or as a MUST) for PA and as a SHOULD for PT. =20 [PS] Ok, will try to reword. I'll note that this text is informative and the normative requirements are in section 7 (which do require support for strong security.) This text is (as you said) supportive rationale for why such security services are needed.=20 =20 Section 8.1.3 Server Components - Shouldn't this section precede 8.1.2? - Only the first and last sentence of the second paragraph is needed....the middle ones seem superfluous. [PS] Not sure I see them as superfluous as they describe what is meant by "network footprint" and "internal workings". Is there something specific of concern about these sentences or is it just that its believed they are unneeded (obvious?) =20 - The last paragraph reads squishy as well, especially the last sentence. I presume by "different systems", it is intended to say "the components physically reside in different hosts".=20 [PS] Yes, i've added your text. =20 The last sentense should be more direct in stating "When there is physical separation, the communications between the NEA Server components must ensure that the PB Session and PA Message Dialogs are resistant to active and passive attacks, in particular, guarded against eavesdropping, forgery and replay." [PS] Thanks will change the words =20 Section 8.2 Overlapping protections - I would not exactly call the protections as overlapping, as each mechanism and protocol had its own security requirements. While it may be true that deployments may not wish to afford the costs in security every layer and stack for NEA, I would not construe them as "overlapping". A more appropriate title would be "Protection Policy" [PS] Understood, several folks have asked why we are requiring these (perceived overlapping) protections at each layer. Will change the section name. =20 - In some instances, especially when the Posture Validator is resident in the NEA Server, it may be acceptable to only encrypt the transport, but in general, such assumptions can not be made. Thus, I have a problem with this section as it seems to make assertions that this is generally acceptable. =20 [PS] Where does it assert that a particular protection should be made? It points out why we require strong security protections in each protocol and ultimately the deployer decides which mix to use based on their environment. The goal of this section is to help justify the requirement for cryptographic security services at each layer and not to dictate when they are used so if you see something misleading please let us know. =20 - This section should state that consideration for Policy configuration to allow for the relaxation of protection, say, at the PA when assurances are afforded by the PT may be allowed. However, care must be taken to assure that proper protection is provided for that particular deployment to meet the security goals of the NEA charter and requirements. [PS] This sounds like its giving the deployer advise on when to use certain protections. This draft is merely providing context and definition of requirements to be used by the NEA WG during protocol selection. 8.2 is hoping to help justify some of the requirements for cryptographic security services in section 7 and raises the need for the deployer to be able to control (via policy) when these services are actually used. This is the separation of the requirement to be supported by a candidate protocol vs. the lack of a requirement for a deployer to use these services as deemed necessary.=20 =20 Section 8.3.1 MiTM - This, like most of the security sections are too wordy. Mutual authentication of the PT link doesn't really guard against a MitM as the attacker can still listen in on the dialog. It is the=20 =20 [PS] Correct and as the section states this is for active MiTM protection (not passive.) =20 protection of the transport itself to guard against any injection such as forgery, replay or any packet injection/spoofing is the consideration to be stated as a requirement. Furthermore, to disable a MitM from discerning the content of the information being passed, confidentiality must also be considered to guard against eavesdropping; but this latter one, isn't really considered a MitM attack. - The notion of establishing mutual authentication is a good one, but is not one for MiTM but rather to ensure that only authorized links between NEA Server and NEA Client are established. Perhaps that should be the focus of this section as succeeding sections already describe the need for confidentiality, integrity and replay protection. =20 [PS] Not sure what to make of this comment as it seems consistent with what was written (maybe your point is 2 paragraphs is too much ... wordy.) Since this section is informative and providing rationale for the requirements, its not clear 2 paragraphs is an issue. The 1st paragraph talks about the potential for a MiTM attack and the 2nd talks about how mutual authentication and secure communications (tied to the authentication) prevent the passive and active MiTM from attacking the protocols. I added a sentence to include the replay prevention in case it were possible for an attacker to replay encrypted messages without detection (although replay is the topic for section 8.3.3) =20 Sections 8.3.2, 8.3.3 and 8.3.4 could be better summarized into one section that describes the different protections: confidentiality, integrity and replay to guard against the different attacks. They currently seem wordy and somewhat redundant as they are described in more than one section. [PS] Will consider this suggestion. The 8.3 section is oriented towards "Relevant Classes of Attack" which seems appropriate for a Security Considerations section as per guidance from RFC 3552, section 5. Whether we structure the section by attack or countermeasure we get to the same information - potential attacks to be considered and countermeasures that should be required. It sound like this comment is to include less background information to reduce the amount of text/wordiness. It will be interesting to see if other agree that this is an issue or is beneficial. =20 =20 Section 9 Privacy Considerations - As this is a requirement specification, this section could also be shorted to only list the requirement considerations. There are two main points that need to be described in this section: (1) As privacy issues may be regulated and governed by enterprises, institutions and even governments users may be restricted to software or even networks based on such regulation. (2) Configuration management and control of an endpoint may be administered by the physical user but constrained to the privacy guidelines as regulated by the enterprise and/or government. There is other text mentioning scope of WG and what NEA technology enables that need not be (redundantly) described here. =20 [PS] I do think this section could be shorter but we need to see what the consensus is for which portions to remove. Its possible that much of 9.2 could be removed (this was included to "seed discussion".) =20 Section 9.1 Implementation Considerations - this section again, seems overly wordy...also, its focus is more towards NEA Client implementation considerations; suggest to rename the section as such. =20 [PS] Will consider a different name, maybe "Implementation Privacy Considerations". Their have been a number of discussions on the alias involving potential privacy issues with NEA so this section attempts to capture some of these ideas while recognizing that they aren't specific to the protocols we are selecting (so fall more into the realm of implementations.) =20 - it is not clear what is meant by a user to control which networks.....is the user the one that is configuring the NEA solution deployments? Would it be better to refer to the 'administrator' versus a 'user' especially as there is mention of "per-User" access which can be construed as a NEA Client user or as a administrator controlling access? =20 [PS] Added definition of User but this is not intended to be the administrator. The deployer/adminstrator could certainly also impose policy on the NEA components more likely for reasons other then User privacy (unless dictated by local laws/customs.) =20 - 'opt-in' policy? Not sure exactly what this means? Enable use of NEA protocols as a whole? or to particular attributes? =20 [PS] Correct, opt-in is the ability for the User to decide if they wish to share their Posture information and potentially any private information with the network in order to gain access. Several folks on the alias believed it was important that the User be able to readily assert they do not wish to share information (or limit what they do share.) This of course might mean loss of network (or service) access or more limited access based upon the deployer's policy. This might be beneficial in countries with more advanced privacy laws (e.g. EU countries.) =20 - I am somwhat confused to who "user" and "Owner" and "User policies" refer to.....these roles need to be clearly defined and the terms used consistently. =20 [PS] See the definitions in -01 to see if that helps (Owner is defined in -00.) "User policies" are policies expressed by the User of the system that impacts the operation of the NEA Components. "Owner policies" would be expressed by the Owner of the Endpoint. We believe these terms are being used consistently. =20 Section 9.2 Minimizing Attribute Disclosure - the terms "user" "owner" and "deployer" seem to be used inconsistantly to sometimes means the "one" configuring the full deployment, sometimes the "one" using the "endpoint" or the "tag" used to apply "per-User" policy.....and is somewhat confusing. Please add a subset of these in the Terminology section and use them throughout the specification consistantly. =20 [PS] Please reference where you see the inconsistency. =20 =20 - This section is somewhat confusing as it's now clear the direction of policy assessment, or the notion of "policy"? For instance: - this section implies that a "policy" is defined by a "set of attributes" but is not explicitly clarified? =20 =20 [PS] A privacy policy might be expressed as a set of attributes which are allowed to be shared with a network. NEA isn't defining policy syntax nor semantics so these are just considerations for implementers wishing to create privacy friendly products (as stated in 9.1). =20 - this section implies that there is "policy" at the Endpoint which can limit the information that is provided to the NEA Server? Why couldn't this be negotiated between Client and Server? =20 [PS] Sure it could be a negotiation that would reflect the policies of both parties so something would still need to be expressed on the Endpoint. It also could be the NEA Server asks for a set of Attributes and the Client responds with those it is configured to share with this network and the Server decides if that is sufficient or whether additional Attributes are needed (or it may just deny/limit access based on what was disclosed.) This is the third model described in 9.2. =20 - these seem to describe different mechanisms for realizing one model? That is, the model where the client is provided "policy" of which attributes it may share with the Server to serve as a filter. =20 [PS] The point of 9.2 was to "seed discussion" on models for Attribute exchange and their impact on User privacy. This discussion may decide this section isn't useful (long term) or to focus it on an agreed upon smaller set of models for the eventual RFC. We're hoping the WG will have some discussions of this section and it will be significantly simplified. Before the Prague meeting we'll prompt this discussion if it doesn't happen organically. =20 - This last paragraph implies that only 1 privacy filter is needed? What about an Endpoint that is mobile and may need to adhere to different privacy policies based on government regulations? (or Inside vs. Outside an enterprise?) =20 [PS] The privacy policies are per-network. We'll clean up the last paragraph so this is more consistent with earlier text. =20 Regards, Nancy. ------_=_NextPart_001_01C76965.6942BEC6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just realized my 3/5 response to Nancy's = comments didn't=20 also go to the alias.

From: Paul Sangster =
Sent: Monday,=20 March 05, 2007 8:25 PM
To: 'Nancy Winget=20 (ncamwing)'
Subject: RE: [Nea] NEA requirements draft=20 comments

Thanks for your comments, many of the = responses below=20 were included in the (now published) -01 I-D (just didn't have time to = send=20 out the response).  Comments with [PS] = prefix...
From: Nancy Winget (ncamwing)=20 [mailto:ncamwing@cisco.com]
Sent: Tuesday, February 27, = 2007 5:27=20 PM
To: nea@ietf.org
Subject: [Nea] NEA = requirements=20 draft comments

Hi,
 
I = reviewed the=20 requirements and security considerations of the NEA requirements = draft and=20 have some comments below:
 
General:
    - the terms Client and NEA Client, = are used=20 interchangeably; only one term should be chosen and used = consistantly. =20 Similary for Server and NEA Server.
 
[PS] Reviewed=20 the draft and fixed these ambiguities (however left uses = of "NEA=20 Client and Server" which seems clear enough.  Some uses of = "server"=20 were also appropriate.  Didn't find any examples of "Client" or = "Server" (capitalized) without a NEA oriented=20 prefix.
 
Section 2.=20 Terminology
    - Should add the following terms as they = are used=20 throughout the draft: Validator (or Posture Validator and use only = one of=20 these terms), NEA Client, NEA Server, NEA Component
 
[PS] These are = described=20 in the Reference Model section.  We felt these needed more = context then=20 a short definition.
 
    - consider adding one or two terms for: = User,=20 Owner, Deployer, Administrator
 
[PS] Added = "User" which we=20 had intended to define all along and Deployer.  Owner was = already=20 defined.  Will consider adding others as well although = some have=20 expressed a concern about our defining terms for too many generic = (well=20 known) words.  User and Owner were important for the privacy=20 considerations section so were=20 desired.
 
    - Policy:  there is much mention of = the=20 general term "policy" which at times is a configuration option, at = times a=20 set of "Policy Attributes" and at times something else, that needs = to be=20 clarified and defined in this section.
 
[PS] Policy = Attributes are=20 defined.  Not sure if we want to try to define something = specific=20 for the term policy but am open to feedback on this (including text=20 contributions.) 
 
Section=20 7.1 Common Protocol Requirements
 
[PS] We will = discuss=20 section 7 at a later date as our current focus is on the context = setting=20 sections.  We appreciate the comments and will respond to these = separately. 
 
    - the protocol requirements put forth imply that there is a = predefined means by which the client and server know how to reach = each=20 other.  This could be implied or also assumed by the underlying = protocol, but is not mentioned in either the requirements, = assumptions or=20 considerations sections.  While there is mention to this in the = architecture section, there should be more clear mention as to such=20 assumptions in either Section 7 or Section 8 as = well.
    - while the individual requirements for the PA, PB and PT = protocols=20 call out for confidentiality and integrity, the common section does=20 not.  While C-4 speaks to protection against active, passive = and replay=20 attacks, there is no mention to forgery or eavesdropping=20 attacks?
 
 
Section 7.4=20 Posture Transport (PT) Protocol Requirements
    - Should PT-5 also include = retransmissions?
    =
Section 8.1=20 Trust
    - This paragraph is too leading and can be construed to = attempt to=20 impose further security requirements versus a descriptive statement = to=20 assert that the trustworthiness of the attribute contents is beyond = the=20 scope of this body.  Further the security requirements imposed = on the=20 PA, PB and PT are to establish trust between the NEA Client and NEA = Server=20 but does not assert trust of the Endpoint hosting the NEA = Client.  My=20 suggestion is to reword the first paragraph of this section to = something=20 like:
    "Network Endpoint Assement enables NEA = Clients and=20 NEA Servers to communicate Posture information that is assessed = by=20 Posture Validators.  The trust relationship established between = the NEA=20 Client and NEA Server is used to securely exchange attributes but is = not=20 intended to provide assuranses to the trustworthiness of the=20 Endpoint."
 
[PS] Based on = others=20 prior comments the initial sentence was replaced with = something=20 closer to what you have=20 suggested. 
 
Section 8.1.1=20 Client Components
    - 1st sentence of the first paragraph = should read:=20 "For NEA to properly operate, the NEA Client component of the = Endpoint needs to be trusted to accurately represent the requested = security=20 Posture of the Endpoint to the NEA Server."
 
[PS] The = intention was to=20 be more broad as their could be other software on the Endpoint that = might=20 trick the NEA Client into misrepresenting the Posture of the=20 system.  We are trusting that this is not happening and that = the=20 Endpoint is accurately representing its=20 Posture.
 
    - it is not clear to me why the rest of = this first=20 paragraph (e.g. 2nd sentence to end of paragraph) is needed?  = If the=20 point is "The trustworthiness of the contextual information of the=20 attributes themselves is beyond the scope of this draft." then it = should=20 just state that and removed the rest of the text.
 
[PS] This text = is=20 consistent with the NEA WG charter ("However, the protocols = developed=20 by the NEA WG must be designed to accommodate emerging technologies = for=20 identifying and dealing with lying endpoints.") and is one of = the items=20 that needs to be covered by our activities.  This was discussed = at the=20 NEA BOFs.  Unless its not accurate or misleading i would prefer = to see=20 it remain.  What is the concern about this=20 text? 
 
    - The 2nd paragraph should also include = that there=20 must be some inherent trust between the NEA Server with the NEA = Client=20 that is doing the comparison and effective compliance = validation.
 
[PS] Can you = be more=20 specific?  If I understand the comment this is at the heart of = what=20 this paragraph is about.  I made one change (c/we/the NEA=20 Server/) to help clarity but this might not have captured your=20 intent.
 
    - The 3rd paragraph should define what = is meant by=20 "User or Owner" policy.  I assume it is policy configured at = the=20 Endpoint based on a particular User identity?
 
[PS] Its = policy defined by=20 the User and/or Owner of the Endpoint as being authorized for use of = the=20 Endpoint (e.g. firewall rules.)  The details of the policy are=20 mechanism specific.  Changed to "User or Owner defined=20 policy."
 
Section 8.1.2=20 Network Communications
    - The last paragraph of this section = states a=20 rationale for requiring confidentiality, integrity and replay = protection and=20 should be transcribed as such.  It currently reads as being too = passive, where the requirements posted in Section 7 impose some of = these=20 protections as a MUST.  My suggestion is to state that NEA must = guard=20 against such attacks by providing confidentiality, integrity and = replay=20 protection minimally (or as a MUST) for PA and as a SHOULD for = PT.
 
[PS] Ok, will = try to=20 reword.  I'll note that this text is informative and=20 the normative requirements are in section 7 (which do require = support=20 for strong security.)  This text is (as you said) supportive = rationale=20 for why such security services are=20 needed. 
 
Section 8.1.3=20 Server Components
    - Shouldn't this section precede 8.1.2?
    - Only the first and last sentence of = the second=20 paragraph is needed....the middle ones seem superfluous.
[PS] Not sure = I see them=20 as superfluous as they describe what is meant by "network footprint" = and=20 "internal workings".  Is there something specific of concern = about=20 these sentences or is it just that its believed they are unneeded=20 (obvious?)
 
    - The last paragraph reads squishy as well, especially the = last=20 sentence.  I presume by "different systems", it is intended to = say "the=20 components physically reside in different hosts". 
[PS] Yes, i've = added your=20 text.
 
  The last = sentense should=20 be more direct in stating "When there is physical separation, the=20 communications between the NEA Server components must ensure that = the PB=20 Session and PA Message Dialogs are resistant to active and passive = attacks,=20 in particular, guarded against eavesdropping, forgery and = replay."
[PS] Thanks = will change=20 the words
 
Section 8.2=20 Overlapping protections
    - I would not exactly call the = protections as=20 overlapping, as each mechanism and protocol had its own security=20 requirements.  While it may be true that deployments may not = wish to=20 afford the costs in security every layer and stack for NEA, I would = not=20 construe them as "overlapping".  A more appropriate title would = be=20 "Protection Policy"
[PS] Understood, several folks have asked why = we are=20 requiring these (perceived overlapping) protections at each = layer. =20 Will change the section = name.
 
    - In some instances, especially when the = Posture=20 Validator is resident in the NEA Server, it may be = acceptable to=20 only encrypt the transport, but in general, such assumptions can not = be=20 made.  Thus, I have a problem with this section as it seems to = make=20 assertions that this is generally acceptable. 
[PS] Where = does it assert=20 that a particular protection should be made?  It points out why = we=20 require strong security protections in each protocol and ultimately = the=20 deployer decides which mix to use based on their environment.  = The goal=20 of this section is to help justify the requirement for cryptographic = security services at each layer and not to dictate when they are = used so if=20 you see something misleading please let us=20 know.
 
    - This section should state that = consideration for=20 Policy configuration to allow for the relaxation of protection, say, = at the=20 PA when assurances are afforded by the PT may be allowed.  = However,=20 care must be taken to assure that proper protection is provided for = that=20 particular deployment to meet the security goals of the NEA charter = and=20 requirements.
[PS] This sounds like its giving the deployer = advise on=20 when to use certain protections.  This draft is merely = providing=20 context and definition of requirements to be used by the NEA WG = during=20 protocol selection.  8.2 is hoping to help justify some of = the=20 requirements for cryptographic security services in section 7=20 and raises the need for the deployer to be able to control (via = policy)=20 when these services are actually used.  This is the = separation of=20 the requirement to be supported by a candidate protocol vs. the lack = of a=20 requirement for a deployer to use these services as deemed=20 necessary. 
 
Section 8.3.1=20 MiTM
    - This, like most of the security = sections are too=20 wordy.  Mutual authentication of the PT link doesn't really = guard=20 against a MitM as the attacker can still listen in on the = dialog.  It=20 is the 
 
[PS] Correct = and as the=20 section states this is for active MiTM protection (not=20 passive.)
 
protection of=20 the transport itself to guard against any injection such as forgery, = replay=20 or any packet injection/spoofing is the consideration to be stated = as a=20 requirement.  Furthermore, to disable a MitM from discerning = the=20 content of the information being passed, confidentiality must also = be=20 considered to guard against eavesdropping; but this latter = one,=20 isn't really considered a MitM attack.
    - The notion of establishing mutual = authentication=20 is a good one, but is not one for MiTM but rather to ensure that = only=20 authorized links between NEA Server and NEA Client are = established. =20 Perhaps that should be the focus of this section as succeeding = sections=20 already describe the need for confidentiality, integrity and replay=20 protection.
 
[PS] Not sure = what to make=20 of this comment as it seems consistent with what was written (maybe = your=20 point is 2 paragraphs is too much ... wordy.)  Since this = section is=20 informative and providing rationale for the requirements, its not = clear 2=20 paragraphs is an issue.  The 1st paragraph talks about the = potential=20 for a MiTM attack and the 2nd talks about how mutual authentication = and=20 secure communications (tied to the authentication) prevent the = passive and=20 active MiTM from attacking the protocols.  I added a sentence = to=20 include the replay prevention in case it were possible for an = attacker to=20 replay encrypted messages without detection (although replay is the = topic=20 for section 8.3.3)
 
Sections=20 8.3.2, 8.3.3 and 8.3.4 could be better summarized into one section = that=20 describes the different protections: confidentiality, integrity and = replay=20 to guard against the different attacks.  They currently = seem wordy=20 and somewhat redundant as they are described in more than one=20 section.
[PS] Will consider this suggestion.  The = 8.3 section=20 is oriented towards "Relevant Classes of Attack" which seems=20 appropriate for a Security Considerations section as per = guidance from=20  RFC 3552, section 5.  Whether we structure the section by = attack=20 or countermeasure we get to the same information - potential attacks = to be=20 considered and countermeasures that should be required.  = It sound=20 like this comment is to include less background information to = reduce the=20 amount of text/wordiness.  It will be interesting to see if = other agree=20 that this is an issue or is=20 beneficial.
 
 
Section 9=20 Privacy Considerations
    - As this is a = requirement=20 specification, this section could also be shorted to only list=20 the requirement considerations.   There are two main points = that need to=20 be described in this section: (1) As privacy issues may be regulated = and=20 governed by enterprises, institutions and even governments users may = be=20 restricted to software or even networks based on such = regulation.  (2)=20 Configuration management and control of an endpoint may be = administered by=20 the physical user but constrained to the privacy guidelines as = regulated by=20 the enterprise and/or government.  There is other text = mentioning scope=20 of WG and what NEA technology enables that need not be (redundantly) = described here.
 
[PS] I do think this = section could be=20 shorter but we need to see what the consensus is for which = portions to=20 remove.  Its possible that much of 9.2 could be removed (this = was=20 included to "seed discussion".)
 
Section 9.1=20 Implementation Considerations
    - this section again, seems overly = wordy...also, its=20 focus is more towards NEA Client implementation considerations; = suggest to=20 rename the section as such.
 
[PS] Will = consider a=20 different name, maybe "Implementation Privacy Considerations".  = Their=20 have been a number of discussions on the alias involving potential = privacy=20 issues with NEA so this section attempts to capture some of these = ideas=20 while recognizing that they aren't specific to the protocols we are=20 selecting (so fall more into the realm of=20 implementations.)
 
    - it is not clear what is meant by a = user to control=20 which networks.....is the user the one that is configuring the NEA = solution=20 deployments?  Would it be better to refer to the = 'administrator' versus=20 a 'user' especially as there is mention of "per-User" access which = can be=20 construed as a NEA Client user or as a administrator controlling=20 access?
 
[PS] Added = definition=20 of User but this is not intended to be the administrator.  = The=20 deployer/adminstrator could certainly also impose policy on the NEA=20 components more likely for reasons other then User privacy (unless = dictated=20 by local laws/customs.)
 
    - 'opt-in' policy?  Not sure = exactly what this=20 means?  Enable use of NEA protocols as a whole?  or to = particular=20 attributes?
 
[PS] Correct, = opt-in is=20 the ability for the User to decide if they wish to share = their=20 Posture information and potentially any private information with the = network=20 in order to gain access.  Several folks on the alias believed = it was=20 important that the User be able to readily assert they do not wish = to share=20 information (or limit what they do share.)  This of course = might mean=20 loss of network (or service) access or more limited access based = upon the=20 deployer's policy.  This might be = beneficial=20 in countries with more advanced privacy laws (e.g. EU=20 countries.)
 
    - I am somwhat confused to who "user" = and "Owner"=20 and "User policies" refer to.....these roles need to be clearly = defined and=20 the terms used consistently.
 
[PS] See the = definitions=20 in -01 to see if that helps (Owner is defined in -00.)  "User = policies"=20 are policies expressed by the User of the system that impacts = the=20 operation of the NEA Components. "Owner policies" would be = expressed by the Owner of the Endpoint.  We believe these terms = are=20 being used consistently.
 
Section 9.2=20 Minimizing Attribute Disclosure
    - the terms "user" "owner" and = "deployer" seem to be=20 used inconsistantly to sometimes means the "one" configuring the = full=20 deployment,  sometimes the "one" using the "endpoint" or the = "tag" used=20 to apply "per-User" policy.....and is somewhat confusing.  = Please add a=20 subset of these in the Terminology section and use them throughout = the=20 specification consistantly.
 
[PS] Please = reference=20 where you see the inconsistency. =20
 
    - This section is somewhat confusing as it's now clear the = direction=20 of policy assessment, or the notion of "policy"?  For=20 instance:
        = - this section implies that a "policy" = is defined by=20 a "set of attributes" but is not explicitly = clarified?  
 
[PS] A privacy = policy=20 might be expressed as a set of attributes which are allowed to be = shared=20 with a network.  NEA isn't defining policy syntax nor = semantics so=20 these are just considerations for implementers wishing to create = privacy=20 friendly products (as stated in=20 9.1).
 
        = - this section implies that there is = "policy" at the=20 Endpoint which can limit the information that is provided to the NEA = Server?  Why couldn't this be negotiated between Client and=20 Server?
 
[PS] Sure it = could be a=20 negotiation that would reflect the policies of both parties so = something=20 would still need to be expressed on the Endpoint.  It also = could be the=20 NEA Server asks for a set of Attributes and the Client responds with = those=20 it is configured to share with this network and the Server decides = if that=20 is sufficient or whether additional Attributes are needed (or it may = just=20 deny/limit access based on what was disclosed.)  This is the=20 third model described in = 9.2.
 
        = - these seem to describe different = mechanisms for=20 realizing one model?  That is, the model where the client is = provided=20 "policy" of which attributes it may share with the Server to serve = as a=20 filter.
 
[PS] The point = of 9.2 was=20 to "seed discussion" on models for Attribute exchange and their = impact on=20 User privacy.  This discussion may decide this section isn't = useful=20 (long term) or to focus it on an agreed upon smaller set of models = for the=20 eventual RFC.  We're hoping the WG will have some = discussions of=20 this section and it will be significantly=20 simplified.  Before the Prague meeting we'll prompt = this=20 discussion if it doesn't happen = organically.
 
    - This last paragraph implies that only = 1 privacy=20 filter is needed?  What about an Endpoint that is mobile and = may need=20 to adhere to different privacy policies based on government = regulations? (or=20 Inside vs. Outside an enterprise?)
 
[PS] The = privacy policies=20 are per-network.  We'll clean up the last paragraph = so this is=20 more consistent with earlier text.
 
Regards,
  =20 = Nancy.
<= /BODY> ------_=_NextPart_001_01C76965.6942BEC6-- --===============1691992226== 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 --===============1691992226==-- From nea-bounces@ietf.org Mon Mar 19 04:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDh7-0007V0-E1; Mon, 19 Mar 2007 04:58:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDh6-0007Uv-3n for nea@ietf.org; Mon, 19 Mar 2007 04:58:20 -0400 Received: from ccerelbas04.cce.hp.com ([161.114.21.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTDgy-00041R-UX for nea@ietf.org; Mon, 19 Mar 2007 04:58:20 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id 9817A3435F; Mon, 19 Mar 2007 03:58:12 -0500 (CDT) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 03:57:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Remote Posture Validators Date: Mon, 19 Mar 2007 08:57:50 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110130D613@G3W0072.americas.hpqcorp.net> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A0268C4DF@SVL1XCHCLUPIN02.enterprise.veritas.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Nea] Remote Posture Validators Thread-Index: AcdgCH8fRq7SgjxdQiKfMh2FgA9sHQAA7MagAn3PeGA= References: <5A58F967CBEBBB4A82DF126CF8A9596A0268C4DF@SVL1XCHCLUPIN02.enterprise.veritas.com> From: "Sanchez, Mauricio (ProCurve)" To: "Paul Sangster" , "nea" X-OriginalArrivalTime: 19 Mar 2007 08:57:56.0793 (UTC) FILETIME=[AFF68290:01C76A04] X-Spam-Score: 0.0 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 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="===============0562390502==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============0562390502== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0018_01C76A0D.0DA00B20"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multipart message in MIME format. ------=_NextPart_000_0018_01C76A0D.0DA00B20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0019_01C76A0D.0DA00B20" ------=_NextPart_001_0019_01C76A0D.0DA00B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My vote would be for a slightly different flavor of option #2. Given that a remote PV protocol is not within current WG scope, I say that describing the existence of remote PVs should only be as it relates to requirements for PA or PB. Otherwise, I don't see a strong argument as to why it needs to be mentioned, since whether you include it or not, the reference model doesn't change. MS From: Paul Sangster [mailto:Paul_Sangster@symantec.com] Sent: Tuesday, March 06, 2007 5:32 PM To: nea Subject: RE: [Nea] Remote Posture Validators Just to be clear on the question, because we are not chartered to define requirements (nor select) a remote PV protocol, would the WG prefer: 1) We not mention remote validators in the spec 2) We acknowledge their existance largely for discussing their impact on the architecture, considerations (security, privacy and other) similar to our current coverage 3) Increase the discussion of remote validators in some way (explain how) Paul _____ From: Mani, Mahalingam (Mani) [mailto:mmani@avaya.com] Sent: Tuesday, March 06, 2007 8:00 AM To: nea Subject: [Nea] Remote Posture Validators On the topic of whether Posture Validators need to be collocated to the Posture Broker Server (PBS) in the NEA Server In the -00 and -01 drafts (5.1.2) it is stated that the Posture Validator (PV) to be located on another server than the PBS requiring the PBS to deal with local and remote PVs. In writing this section we had discussed at length the pros and cons of supporting remote PVs on whether this should be a requirement going forward. While remote PVs provide the flexibility of running on independent platforms (or on related servers if any), they carry the additional burden of establishing a trust relationship with the PBS(s) and also the question of standardizing PBS<->PV transport; among other considerations. We would like to get the WG's thoughts on this. Regards, -mani ------=_NextPart_001_0019_01C76A0D.0DA00B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My vote would be for a slightly different flavor of = option #2.  Given that a remote PV protocol is not within current WG scope, I say that = describing the existence of remote PVs should only be as it relates to requirements = for PA or PB.   Otherwise, I don’t see a strong argument as to = why it needs to be mentioned, since whether you include it or not, the reference model = doesn’t change. 

 

MS

 

From:= Paul = Sangster [mailto:Paul_Sangster@symantec.com]
Sent: Tuesday, March 06, 2007 5:32 PM
To: nea
Subject: RE: [Nea] Remote Posture = Validators

 

Just to be clear on the question, because we are not = chartered to define requirements (nor select) a remote PV protocol, would the WG = prefer:

 

1) We not mention remote validators in the = spec

2) We acknowledge their existance largely for discussing = their impact on the architecture, considerations (security, privacy and other) similar to our current coverage

3) Increase the discussion of remote validators in some way (explain how)

 

Paul

 

From: Mani, Mahalingam (Mani) [mailto:mmani@avaya.com]
Sent: Tuesday, March 06, 2007 8:00 AM
To: nea
Subject: [Nea] Remote Posture Validators

On the topic of whether Posture Validators need to be collocated to the = Posture Broker Server (PBS) in the NEA Server

In the -00 and -01 drafts (5.1.2) it is stated that the Posture Validator = (PV) to be located on another server than the PBS

requiring the PBS to deal with local and remote PVs.

 

In writing this section we had discussed at length the pros and cons of = supporting remote PVs on whether this should be a requirement going = forward.

 

While remote PVs provide the flexibility of running on independent platforms = (or on related servers if any), they carry the additional burden of = establishing a trust relationship with the PBS(s) and also the question of = standardizing PBS<->PV transport; among other = considerations.

 

We would like to get the WG’s thoughts on this.

 

Regards,=

-mani

------=_NextPart_001_0019_01C76A0D.0DA00B20-- ------=_NextPart_000_0018_01C76A0D.0DA00B20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMxOTA4NTc0OVowIwYJ KoZIhvcNAQkEMRYEFKGgXzUr5ailE68ztG2azgby15jlMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgA5ODKzsL0iGr8jBiFG0jzBadHwYQOfGZ5+5QwUGeGZxGMGdYyh41jRnMiOgkTrd NimNoCXFawhD7QxDe462G1LlaHjtJXOJqQpa/foKkN8o+94isXywlKm6be8pB9yWYW8g6/xHeq3H o7CX6GthXs0lKlFsK/tmGgxGcgugseklAAAAAAAA ------=_NextPart_000_0018_01C76A0D.0DA00B20-- --===============0562390502== 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 --===============0562390502==-- From nea-bounces@ietf.org Tue Mar 20 10:38: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 1HTfT5-0006q4-EO; Tue, 20 Mar 2007 10:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfT3-0006py-Qp for nea@ietf.org; Tue, 20 Mar 2007 10:37:41 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTfSv-00058u-Dc for nea@ietf.org; Tue, 20 Mar 2007 10:37:41 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 4A9BE3C0FE for ; Tue, 20 Mar 2007 15:37:18 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08303-01-91 for ; Tue, 20 Mar 2007 15:37:18 +0100 (CET) Received: from [130.129.19.94] (dhcp-135e.ietf68.org [130.129.19.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 615683BEC4 for ; Tue, 20 Mar 2007 15:37:17 +0100 (CET) Message-ID: <45FFF187.9050405@it.su.se> Date: Tue, 20 Mar 2007 15:36:55 +0100 From: Leif Johansson User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: nea@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.797 tagged_above=-99 required=7 tests=[AWL=0.515, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Nea] My schema comments from today 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 Since the chairs encouraged people who went up to the mic today to copy suggestions/requirements to the list here are my 5c: It should imo be a requirement for NEA not to define a new schema language for attributes. After listening to the discussion and reading the requirements document it seems absolutely clear to me that schema in some form is needed and since schema is hard to get right I advocate using an existing schema language instead of inventing another one. Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 21 10:51:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU28l-0004KL-Ac; Wed, 21 Mar 2007 10:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU28i-0004GF-Kg for nea@ietf.org; Wed, 21 Mar 2007 10:50:12 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU28d-0005RB-MF for nea@ietf.org; Wed, 21 Mar 2007 10:50:12 -0400 Received: from [130.129.20.44] (dhcp-142c.ietf68.org [130.129.20.44]) by book.deployingradius.com (Postfix) with ESMTP id CEF43A70B8 for ; Wed, 21 Mar 2007 07:49:13 -0700 (PDT) Message-ID: <460145DA.9030307@deployingradius.com> Date: Wed, 21 Mar 2007 15:48:58 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nea@ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Nea] Comments on -01 re: nomenclature 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 find it hard to understand the document with the multiple Capitalized Terms. I'll restrict my comments in this message to the attributes. I don't see why it's necessary to have Posture Attributes separately from Policy Attributes, or any other type of attribute. I agree with the intent in the document, but the exposition is awkward. I'll explain my reasons, my suggested re-phrasing, and let the group decide if my suggestions make sense. When I see "Posture Attributes" and "Policy Attributes", it looks to me like they are very different things. e.g. A statement by a client saying "I have Manufacturer X, Product Y, Version Z" may not be the same format or type on the wire as a statement by a server saying "you must have Manufacturer X, Product Y, Version Z". Since the statements contain much the same information in both cases, I would expect that they are formatted and/or encoded in much the same way on the wire. This re-use simplifies the specification and implementation. I recognize that the *context* is different in the two cases, of course. We do need to distinguish the two contexts, but linking the context to the attribute seems to me like a layer violation. That is, Posture statements involve attributes sent from a client to a server (perhaps in a "posture statement" message). Policy requirements involve attributes sent from a server to the client. In both cases, the attributes may be identical. The discussion in the document can then be simplified. Rather than saying things like "the client sends Posture attributes", it can be rephrased as "the client sends a Posture Statement". The first phrasing is very different from colloquial English, while the second phrasing is both normative, and understandable as colloquial English. The discussion of which attributes are sent in what message is perhaps a subject best left to later discussion. Therefore, the requirements document should have minimal references to attributes, other than that they exist, and they are to be defined later. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 21 13:50:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4wm-0007L8-GQ; Wed, 21 Mar 2007 13:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4wl-0007KS-4W for nea@ietf.org; Wed, 21 Mar 2007 13:50:03 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU4wi-0002mK-8T for nea@ietf.org; Wed, 21 Mar 2007 13:50:03 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 21 Mar 2007 10:49:59 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2LHnxEd020951; Wed, 21 Mar 2007 10:49:59 -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 l2LHnIZn006038; Wed, 21 Mar 2007 17:49:59 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); Wed, 21 Mar 2007 10:49:27 -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] Comments on -01 re: nomenclature Date: Wed, 21 Mar 2007 10:49:27 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C30333E11F@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <460145DA.9030307@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Comments on -01 re: nomenclature Thread-Index: AcdryIOlEpLA7DLcQGux5nSx91tpTgAFup4w From: "Kaushik Narayan \(kaushik\)" To: "Alan DeKok" , X-OriginalArrivalTime: 21 Mar 2007 17:49:27.0833 (UTC) FILETIME=[45548890:01C76BE1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2401; t=1174499399; x=1175363399; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20Comments=20on=20-01=20re=3A=20nomenclature |Sender:=20; bh=C3etDAnZJtVcvNzHdugjuhFOh14Nfus+dkmFgC7Ow64=; b=MflGNUKGBif1LcZpiOeJMRM/gsPpx+GjkIgnoy/6ypGJAl8X772NAnu1eigW474OIDNhuKvd NBFYLPLSlCWlr/p57R+LGB/xfhZbXsBcshLY9//XaIRGM3CjYytsUnBP; 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: 4d87d2aa806f79fed918a62e834505ca 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 Alan, Please find my reply inline. I don't see why it's necessary to have Posture Attributes separately from Policy Attributes, or any other type of attribute. I agree with the intent in the document, but the exposition is awkward. I'll explain my reasons, my suggested re-phrasing, and let the group decide if my suggestions make sense. When I see "Posture Attributes" and "Policy Attributes", it looks to me like they are very different things. e.g. A statement by a client saying "I have Manufacturer X, Product Y, Version Z" may not be the same format or type on the wire as a statement by a server saying "you must have Manufacturer X, Product Y, Version Z". Since the statements contain much the same information in both cases, I would expect that they are formatted and/or encoded in much the same way on the wire. This re-use simplifies the specification and implementation. I recognize that the *context* is different in the two cases, of course. We do need to distinguish the two contexts, but linking the context to the attribute seems to me like a layer violation. That is, Posture statements involve attributes sent from a client to a server (perhaps in a "posture statement" message). Policy requirements involve attributes sent from a server to the client. In both cases, the attributes may be identical. The discussion in the document can then be simplified. Rather than saying things like "the client sends Posture attributes", it can be rephrased as "the client sends a Posture Statement". The first phrasing is very different from colloquial English, while the second phrasing is both normative, and understandable as colloquial English. The discussion of which attributes are sent in what message is perhaps a subject best left to later discussion. Therefore, the requirements document should have minimal references to attributes, other than that they exist, and they are to be defined later. =20 The Policy Attributes are intended to carry much more than statements of expected values. The policy attributes allow for conditions and rules to passed from the NEA server to the NEA client so that the NEA client can perform an evaluation of the compliance policy. The format of the policy attributes would probably be different from posture attributes. regards, kaushik! _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 21 14:19:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5P8-0005NZ-BC; Wed, 21 Mar 2007 14:19:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5P7-0005NP-F6 for nea@ietf.org; Wed, 21 Mar 2007 14:19:21 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5P2-0004v1-SS for nea@ietf.org; Wed, 21 Mar 2007 14:19:21 -0400 Received: from [130.129.20.44] (dhcp-142c.ietf68.org [130.129.20.44]) by book.deployingradius.com (Postfix) with ESMTP id 2453EA70B8 for ; Wed, 21 Mar 2007 11:19:09 -0700 (PDT) Message-ID: <46017713.2040907@deployingradius.com> Date: Wed, 21 Mar 2007 19:18:59 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nea@ietf.org Subject: Re: [Nea] Comments on -01 re: nomenclature References: <618694EF0B657246A4D55A97E38274C30333E11F@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <618694EF0B657246A4D55A97E38274C30333E11F@xmb-sjc-22d.amer.cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Kaushik Narayan (kaushik) wrote: > The Policy Attributes are intended to carry much more than statements of > expected values. The policy attributes allow for conditions and rules to > passed from the NEA server to the NEA client so that the NEA client can > perform an evaluation of the compliance policy. This will not work. This was pointed out on the list last fall, and again in the WG meeting. People have been trying to express policies in an exchangeable format for years. No one has figured out a generic way to do it *well*. In many cases, policies are implemented in scripts on a server, because there is no other way to get the functionality that is needed. Since policies can in the general case be expressed only as code, the solution is obvious: represent the policies as code. They then get downloaded during remediation, just like new anti-virus rules, or OS patch updates. The only difference is that the "manufacturer" is the administrator of the local network, who writes and maintains those policies. The "policy attribute" then becomes "Yes, I'm running manufacturer X, product Y, version Z". Which, for the network administrator, means that the client has downloaded executed the script he wrote. Since network administrators can write policies this way *anyways* in NEA, adding a complex policy language to the NEA protocol is unwarranted. It adds large amounts of complexity for no benefit. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 21 19:13:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU9zB-0001kL-FG; Wed, 21 Mar 2007 19:12:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU9z7-0001kA-UU for nea@ietf.org; Wed, 21 Mar 2007 19:12:49 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HU9z0-0000NI-Dx for nea@ietf.org; Wed, 21 Mar 2007 19:12:49 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Mar 2007 16:12:41 -0700 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 l2LNCfkw011392; Wed, 21 Mar 2007 16:12:41 -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 l2LNCPEs017880; Wed, 21 Mar 2007 23:12:41 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); Wed, 21 Mar 2007 16:12:37 -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] Comments on -01 re: nomenclature Date: Wed, 21 Mar 2007 16:12:36 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C30333E312@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <46017713.2040907@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Comments on -01 re: nomenclature Thread-Index: Acdr5YlOpF0AVFLUQIeyRy/uAzODNQAJrnNg From: "Kaushik Narayan \(kaushik\)" To: "Alan DeKok" , X-OriginalArrivalTime: 21 Mar 2007 23:12:37.0345 (UTC) FILETIME=[6A614510:01C76C0E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2447; t=1174518761; x=1175382761; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20Comments=20on=20-01=20re=3A=20nomenclature |Sender:=20; bh=2OAE95FxyIzDZoIgKSoNvWXi8tNNQS1h2o3FNUx+z8k=; b=dd6PzmMyV4OWTW7k+tqiiA5Jnt3QquqaIJtVjhp4GWFZHFsxvQVRX5jL+9pArXicJIda2jYB 8Zpuz/DcRhvJaM/MNOvXK75NgzbnxFkbbBn6R7J7euCRGKbU55fkysY2; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Alan, Please find my reply inline. Kaushik Narayan (kaushik) wrote: > The Policy Attributes are intended to carry much more than statements=20 > of expected values. The policy attributes allow for conditions and=20 > rules to passed from the NEA server to the NEA client so that the NEA=20 > client can perform an evaluation of the compliance policy. This will not work. This was pointed out on the list last fall, and again in the WG meeting. People have been trying to express policies in an exchangeable format for years. No one has figured out a generic way to do it *well*. In many cases, policies are implemented in scripts on a server, because there is no other way to get the functionality that is needed. Since policies can in the general case be expressed only as code, the solution is obvious: represent the policies as code. They then get downloaded during remediation, just like new anti-virus rules, or OS patch updates. The only difference is that the "manufacturer" is the administrator of the local network, who writes and maintains those policies. The "policy attribute" then becomes "Yes, I'm running manufacturer X, product Y, version Z". Which, for the network administrator, means that the client has downloaded executed the script he wrote. Since network administrators can write policies this way *anyways* in NEA, adding a complex policy language to the NEA protocol is unwarranted. It adds large amounts of complexity for no benefit. =20 I am not sure that policy attributes need a syntax equivalent of a policy language. I would prefer that we explore the requirements for conditions/expressions to be defined and verify whether we can contain the complexity based on the use cases before being dismissive.=20 I disagree with the assessment that such capability is not beneficial, I think the ability for clients to execute a set of compliance rules significantly reduces the amount of data (attributes) that need to transported to complete an assessment and thereby providing a scalable option for NEA deployments. regards, kaushik! =20 Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Mar 22 05:12:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJKp-0001LZ-Df; Thu, 22 Mar 2007 05:11:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJKo-0001LQ-Aq for nea@ietf.org; Thu, 22 Mar 2007 05:11:50 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUJKm-0001Nv-EH for nea@ietf.org; Thu, 22 Mar 2007 05:11:50 -0400 Received: from [130.129.20.44] (dhcp-142c.ietf68.org [130.129.20.44]) by book.deployingradius.com (Postfix) with ESMTP id 55E1CA70B8; Thu, 22 Mar 2007 02:10:49 -0700 (PDT) Message-ID: <46024813.3050404@deployingradius.com> Date: Thu, 22 Mar 2007 10:10:43 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Kaushik Narayan (kaushik)" Subject: Re: [Nea] Comments on -01 re: nomenclature References: <618694EF0B657246A4D55A97E38274C30333E312@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <618694EF0B657246A4D55A97E38274C30333E312@xmb-sjc-22d.amer.cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Kaushik Narayan (kaushik) wrote: > I am not sure that policy attributes need a syntax equivalent of a > policy language. I would prefer that we explore the requirements for > conditions/expressions to be defined and verify whether we can contain > the complexity based on the use cases before being dismissive. I'm saying many people have tried to solve this problem, and they have failed. I would prefer to avoid re-hashing policy discussions here. If learning from experience is being dismissive, then so be it. If you think you can solve the problem, wonderful. Write a proposal, and the WG can review it. But even if the proposal works, it's unnecessary for reasons I outlined previously, and again below. > I disagree with the assessment that such capability is not beneficial, I > think the ability for clients to execute a set of compliance rules > significantly reduces the amount of data (attributes) that need to > transported to complete an assessment and thereby providing a scalable > option for NEA deployments. I was very clear that exchanging policies *is* beneficial. I was very clear that exchanging policies would reduce the amount of data needed to complete an assessment. The examples I gave directly addressed those two points. My first point is that we don't know *how* to exchange those policies as anything other than executable code. My second point is that the local site admin can write scripts that are downloaded during remediation that implement anything, including complex policy checks. Therefore, we shouldn't try to solve a problem that no one has succeeded in solving when there is already an existing method that works. To put it another way, any policy conditions/expressions that you define *could* be downloaded as part of the NEA protocol. But, they could *also* be downloaded as part of remediation. I think that downloading complex policies (whatever the form) is something better done during remediation than during network access. I don't see why defining complex policy conditions/expressions is a good idea, or why downloading those policies as part of the NEA protocol is a good idea. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Mar 22 12:12:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPkE-00007e-PG; Thu, 22 Mar 2007 12:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPju-0007nu-Qx for nea@ietf.org; Thu, 22 Mar 2007 12:02:10 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUPgK-0001wB-DH for nea@ietf.org; Thu, 22 Mar 2007 11:58:50 -0400 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id F281638C04E for ; Thu, 22 Mar 2007 08:58:27 -0700 (PDT) X-AuditID: d80ac287-9f7d7bb000000de9-6e-4602a7a31fda Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id B9D75348002 for ; Thu, 22 Mar 2007 08:58:27 -0700 (PDT) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HUPgJ-0008HP-LP for nea@ietf.org; Thu, 22 Mar 2007 08:58:27 -0700 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Mar 2007 08:58:27 -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] Comments on -01 re: nomenclature Date: Thu, 22 Mar 2007 08:58:27 -0700 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A027E1AEE@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <46017713.2040907@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Comments on -01 re: nomenclature Thread-Index: Acdr5YBXULGtRnpoQTWObZgZD3UxegAsnRzw References: <618694EF0B657246A4D55A97E38274C30333E11F@xmb-sjc-22d.amer.cisco.com> <46017713.2040907@deployingradius.com> From: "Paul Sangster" To: X-OriginalArrivalTime: 22 Mar 2007 15:58:27.0150 (UTC) FILETIME=[EDAAB6E0:01C76C9A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Taking this topic back up a level (out of how it might work), I do think Alan has a point about the attribute naming giving the *appearance* of implying that a single attribute couldn't be used in multiple of the Attribute Types which would be inefficient. Of course the document doesn't state that an Attribute can only be of a single Attribute Type but it's a reasonable assumption one might make. We could clear this up by stating that this isn't the case or change the names and some descriptive text. After some thought, the issue seems to boil down to we'll likely need a flat attribute space for expressing things and a set of (one or more) attributes may be grouped into a PA Message for performing a particular operation (e.g. requesting posture). As stated 'manufacturer X product Y version Z' might be one or more attributes we wish to use within different types of messages to express part of a [request,posture,assertion,claim]. If we wish to make it more clear that the flat attribute space really isn't subsetted into Attribute Types, we could reword the I-D to talk about attributes being including in a set of Message Types and orient the discussions toward sending certain Message Types for requesting Posture or alike. We might even find that their will be a message type field in the PA message where this gets enumerated. If the WG finds it easier to grok the meaning of message types to indicate the purpose of the included set of attribute we could investigate migrating the I-D text. > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Wednesday, March 21, 2007 11:19 AM > To: nea@ietf.org > Subject: Re: [Nea] Comments on -01 re: nomenclature >=20 > Kaushik Narayan (kaushik) wrote: > > The Policy Attributes are intended to carry much more than=20 > statements=20 > > of expected values. The policy attributes allow for conditions and=20 > > rules to passed from the NEA server to the NEA client so=20 > that the NEA=20 > > client can perform an evaluation of the compliance policy. >=20 > This will not work. This was pointed out on the list last=20 > fall, and again in the WG meeting. >=20 > People have been trying to express policies in an=20 > exchangeable format for years. No one has figured out a=20 > generic way to do it *well*. In many cases, policies are=20 > implemented in scripts on a server, because there is no other=20 > way to get the functionality that is needed. >=20 > Since policies can in the general case be expressed only as=20 > code, the solution is obvious: represent the policies as=20 > code. They then get downloaded during remediation, just like=20 > new anti-virus rules, or OS patch updates. The only=20 > difference is that the "manufacturer" is the administrator of=20 > the local network, who writes and maintains those policies. >=20 > The "policy attribute" then becomes "Yes, I'm running=20 > manufacturer X, product Y, version Z". Which, for the=20 > network administrator, means that the client has downloaded=20 > executed the script he wrote. >=20 > Since network administrators can write policies this way=20 > *anyways* in NEA, adding a complex policy language to the NEA=20 > protocol is unwarranted. It adds large amounts of complexity=20 > for no benefit. >=20 > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Mar 22 13:53:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURTp-0002mT-4r; Thu, 22 Mar 2007 13:53:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURTo-0002lW-1o for nea@ietf.org; Thu, 22 Mar 2007 13:53:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HURTl-00082K-Kn for nea@ietf.org; Thu, 22 Mar 2007 13:53:39 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Mar 2007 13:53:37 -0400 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 l2MHrbPJ019701; Thu, 22 Mar 2007 13:53:37 -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 l2MHrblG009956; Thu, 22 Mar 2007 17:53:37 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); Thu, 22 Mar 2007 13:53:37 -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: Thu, 22 Mar 2007 13:53:32 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF68 NEA WG summary Thread-Index: AcdsWsaKjJnPw/PJQZWtmHaSlXHsqwATeZ9w From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 22 Mar 2007 17:53:37.0250 (UTC) FILETIME=[04684C20:01C76CAB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1899; t=1174586017; x=1175450017; 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:=20FW=3A=20IETF68=20NEA=20WG=20summary |Sender:=20 |To:=20; bh=av5APgTzQZCPmQQ96HwSVp4Yt4CTZQ5bMN8xf6EULg4=; b=UjYRKbl0e6o625gcLqE2XFxBEuZm/N/OQP4/fVKCrUpRMy0JjNZxTDhFkzj2bLrHOBEC0L6x bAkxsYPsrUKbNmKvfR4RlroMXYYtVaTNkEBezTGwOt5uo+Vps3hZ3YRA; 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Nea] FW: IETF68 NEA WG summary 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 FYI. Am forwarding this brief summary of the NEA WG meeting, which is requested by the security ADs of all working groups in the security area during the week of the IETF. More detailed meeting minutes will follow as is usual. Thanks to all those who participated in the NEA WG meeting this week. Susan=20 -----Original Message----- From: Susan Thomson (sethomso)=20 Sent: Thursday, March 22, 2007 4:19 AM To: saag@mit.edu Subject: IETF68 NEA WG summary NEA WG meeting March 20, 2007 1. Charter milestones Original milestones in charter need to be updated. Proposed updates to milestones were reviewed in the meeting. A hum was taken demonstrating=20 support for the changes.=20 Next Steps: Take to list for final review before being sent to AD for approval. 2. Review of Requirements draft Current requirements draft reviewed including reference model, proposed attribute types, and use cases. Open issues were raised on supporting virtualization, security considerations, privacy considerations and NEA support for non-endpoint devices. NEA support for non-endpoint devices may be outside of scope of charter, but our AD indicated that further discussion is warranted to understand the problem better. Next Steps: WG participants and document editors to raise issues on mailing list and continue discussion. Requirements draft to be updated in April based on feedback received.=20 3. Eduroam and NEA There was a short presentation on use of federated 802.1x in FWNA/eduroam deployments, and how it may be impacted by NEA. While it is clear that support for such networks is outside the current NEA charter, the presenters' intent was to raise awareness of potential issues in an attempt to avoid problems with supporting such deployments in the future. Several proposals for resolving the issues without affecting NEA were suggested. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Mar 22 14:54: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 1HUSQW-0006Xy-PS; Thu, 22 Mar 2007 14:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUSQV-0006Xo-Qa for nea@ietf.org; Thu, 22 Mar 2007 14:54:19 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUSQT-0003pX-DN for nea@ietf.org; Thu, 22 Mar 2007 14:54:19 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2007 11:54:16 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2MIsGtB018075; Thu, 22 Mar 2007 11:54:16 -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 l2MIsCEu008315; Thu, 22 Mar 2007 18:54:16 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); Thu, 22 Mar 2007 11:54:09 -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] Comments on -01 re: nomenclature Date: Thu, 22 Mar 2007 11:54:07 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C30333E661@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <46024813.3050404@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Comments on -01 re: nomenclature Thread-Index: AcdsYgd3DJzhsrCwRMCc1wzqt4lw9gARChgQ From: "Kaushik Narayan \(kaushik\)" To: "Alan DeKok" X-OriginalArrivalTime: 22 Mar 2007 18:54:09.0122 (UTC) FILETIME=[792BFC20:01C76CB3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3670; t=1174589656; x=1175453656; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20Comments=20on=20-01=20re=3A=20nomenclature |Sender:=20; bh=JcZ/Zc9zoUhgtngS88pkRUkm3YBvZMnyjZWk/y9y+5A=; b=trDJxqoavNkhCLZlVvRdFxcze07Sp/n97DWeiXkR8V6FAO0s7LbxS1VMMWM825W258tI7fbS wUxWA+Ans7WFbMRwNDWkbAf72JNIwyXi3nFprJKfSKdIe5aopTIJR2Dn; 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: a2c12dacc0736f14d6b540e805505a86 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Alan, Please find my reply inline.=20 Kaushik Narayan (kaushik) wrote: > I am not sure that policy attributes need a syntax equivalent of a=20 > policy language. I would prefer that we explore the requirements for=20 > conditions/expressions to be defined and verify whether we can contain > the complexity based on the use cases before being dismissive. I'm saying many people have tried to solve this problem, and they have failed. I would prefer to avoid re-hashing policy discussions here. If learning from experience is being dismissive, then so be it. If you think you can solve the problem, wonderful. Write a proposal, and the WG can review it. But even if the proposal works, it's unnecessary for reasons I outlined previously, and again below. =20 I understand your concern about trying to standardize expressions in the IETF and that could be a slippery slope, I could see these expressions being vendor/implementation specific rather than trying to specify them in the IETF. I just want to make sure that we don't get too prescriptive about what policy attributes can carry thereby limiting the ability of implementations to introduce such capabilites. Just to clarify, here is what I was thinking about when I meant expression. A typical example would be that NEA server provides the NEA client an "IF THEN ELSE" statement with a list of attributes and expected values. The NEA client can check for different posture attributes based on different conditions being satisfied. > I disagree with the assessment that such capability is not beneficial, > I think the ability for clients to execute a set of compliance rules=20 > significantly reduces the amount of data (attributes) that need to=20 > transported to complete an assessment and thereby providing a scalable > option for NEA deployments. I was very clear that exchanging policies *is* beneficial. I was very clear that exchanging policies would reduce the amount of data needed to complete an assessment. The examples I gave directly addressed those two points. My first point is that we don't know *how* to exchange those policies as anything other than executable code. My second point is that the local site admin can write scripts that are downloaded during remediation that implement anything, including complex policy checks. Therefore, we shouldn't try to solve a problem that no one has succeeded in solving when there is already an existing method that works. To put it another way, any policy conditions/expressions that you define *could* be downloaded as part of the NEA protocol. But, they could *also* be downloaded as part of remediation. I think that downloading complex policies (whatever the form) is something better done during remediation than during network access. I don't see why defining complex policy conditions/expressions is a good idea, or why downloading those policies as part of the NEA protocol is a good idea. I am not sure about the co-relation between conditional checks executed by the client and remediation since such checks would be very useful in optimizing the attribute exchange during assessment (initial or periodic). Remediation is the process of patching a non-compliant endpoint to bring it back to compliant state and a NEA client could go through several assessments and not require any remediation. regards, kaushik! Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Mar 23 03:06:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUdqL-0002H3-CQ; Fri, 23 Mar 2007 03:05:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUdqJ-0002Dk-TO for nea@ietf.org; Fri, 23 Mar 2007 03:05:43 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUdq7-0003cg-IA for nea@ietf.org; Fri, 23 Mar 2007 03:05:43 -0400 Received: from [10.115.12.194] (unknown [80.187.209.9]) by book.deployingradius.com (Postfix) with ESMTP id BFECF11A572; Fri, 23 Mar 2007 00:05:10 -0700 (PDT) Message-ID: <46037C20.2080305@deployingradius.com> Date: Fri, 23 Mar 2007 08:05:04 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Kaushik Narayan (kaushik)" Subject: Re: [Nea] Comments on -01 re: nomenclature References: <618694EF0B657246A4D55A97E38274C30333E661@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <618694EF0B657246A4D55A97E38274C30333E661@xmb-sjc-22d.amer.cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Kaushik Narayan (kaushik) wrote: > I understand your concern about trying to standardize expressions in the > IETF and that could be a slippery slope, I could see these expressions > being vendor/implementation specific rather than trying to specify them > in the IETF. Vendors do that now. They call it "software". > Just to clarify, here is what I was thinking about when I meant > expression. A typical example would be that NEA server provides the NEA > client an "IF THEN ELSE" statement with a list of attributes and > expected values. The NEA client can check for different posture > attributes based on different conditions being satisfied. I understand. > I am not sure about the co-relation between conditional checks executed > by the client and remediation since such checks would be very useful in > optimizing the attribute exchange during assessment (initial or > periodic). That's about the third time you've said that. I don't think we're communicating. > Remediation is the process of patching a non-compliant > endpoint to bring it back to compliant state and a NEA client could go > through several assessments and not require any remediation. I understand. Since you're just repeating your position and I'm just repeating mine, this discussion is at a close. I believe I understand what you're trying to do. I believe my proposal addresses your goal. I have seen no reason why policies have to be exchanged in the NEA protocol, rather than elsewhere. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Mar 23 21:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUuq9-0007P0-GR; Fri, 23 Mar 2007 21:14:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUuq8-0007On-0Y for nea@ietf.org; Fri, 23 Mar 2007 21:14:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUuq6-0005oo-NE for nea@ietf.org; Fri, 23 Mar 2007 21:14:39 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2007 18:14:38 -0700 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 l2O1Ec0u003893; Fri, 23 Mar 2007 18:14:38 -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 l2O1EXEi001675; Sat, 24 Mar 2007 01:14:37 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); Fri, 23 Mar 2007 18:14:33 -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] Comments on -01 re: nomenclature Date: Fri, 23 Mar 2007 18:14:35 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3033B18DF@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <46037C20.2080305@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Comments on -01 re: nomenclature Thread-Index: AcdtGaldm5363sPTQqWPrRwrUFPunwAl2YkA From: "Kaushik Narayan \(kaushik\)" To: "Alan DeKok" X-OriginalArrivalTime: 24 Mar 2007 01:14:33.0559 (UTC) FILETIME=[C8026E70:01C76DB1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=766; t=1174698878; x=1175562878; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20Comments=20on=20-01=20re=3A=20nomenclature |Sender:=20; bh=7PIwhUEjYTZ68ZUjjhJMx3rz5VbxnZekVvOz6Pb4ozo=; b=MQf6/t3Tu9QZ6nuTiHN6Nqn06F2qXXq2wKreNtQeTg8l9i303ZhwgJlXwBifE3418/MKesMY lBEtVz8T5EY7HNe1xu0OB1LoxgXf0LwVAJz1dIy6SUBYNnkEtSbo92JNS2hA60wC+UQpIGdgZ8 ed+ipS3Gif5Vv1scuiSr811WU=; Authentication-Results: sj-dkim-1; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Alan, Please find my reply inline. =20 > Remediation is the process of patching a non-compliant endpoint to=20 > bring it back to compliant state and a NEA client could go through=20 > several assessments and not require any remediation. I understand. Since you're just repeating your position and I'm just repeating mine, this discussion is at a close. I believe I understand what you're trying to do. I believe my proposal addresses your goal. I have seen no reason why policies have to be exchanged in the NEA protocol, rather than elsewhere. I think we can agree to disagree on this point however I don't think our disagreement impacts the NEA protocol requirements. regards, kaushik _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Mar 26 22:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW1kK-0008IK-Pd; Mon, 26 Mar 2007 22:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW1kJ-0008Dl-Gn for nea@ietf.org; Mon, 26 Mar 2007 22:49:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW1kH-0006ey-5X for nea@ietf.org; Mon, 26 Mar 2007 22:49:15 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2R2n4Cx037270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2007 19:49:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <618694EF0B657246A4D55A97E38274C3033B18DF@xmb-sjc-22d.amer.cisco.com> References: <618694EF0B657246A4D55A97E38274C3033B18DF@xmb-sjc-22d.amer.cisco.com> Date: Mon, 26 Mar 2007 15:56:17 +0200 To: nea@ietf.org From: Paul Hoffman Subject: RE: [Nea] Comments on -01 re: nomenclature Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 At 6:14 PM -0700 3/23/07, Kaushik Narayan \(kaushik\) wrote: > > >I think we can agree to disagree on this point however I don't think our >disagreement impacts the NEA protocol requirements. I fully disagree. What Alan is asking for is to collapse Posture Attributes with Policy Attributes; I agree with his request and his logic. I have not seen a concrete example of a Policy Attribute that does not have an identical analog in a Posture Attribute. For every "I am going to want X&Y&Z" or "I demand X&Y&Z", there is an equivalent "I do X&Y&Z". If someone can show me a Policy Attribute that doesn't have an analog Posture Attribute, it would help me resolve this issue. On a separate topic, I agree with Alan that Overuse Of Capitalization makes the document harder to read. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 28 15:46: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 1HWe5c-0006cb-Ll; Wed, 28 Mar 2007 15:45:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWe5b-0006cW-O1 for nea@ietf.org; Wed, 28 Mar 2007 15:45:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWe5a-000135-Ar for nea@ietf.org; Wed, 28 Mar 2007 15:45:47 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Mar 2007 12:45:46 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2SJjjjH000663; Wed, 28 Mar 2007 12:45:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2SJjbEo027385; Wed, 28 Mar 2007 19:45:37 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); Wed, 28 Mar 2007 12:45:37 -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] Comments on -01 re: nomenclature Date: Wed, 28 Mar 2007 12:45:35 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3033B26A9@xmb-sjc-22d.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Comments on -01 re: nomenclature Thread-Index: AcdwGz/PJ8e/pCw6Tve060VTgmvxAABVc/kw From: "Kaushik Narayan \(kaushik\)" To: "Paul Hoffman" , X-OriginalArrivalTime: 28 Mar 2007 19:45:37.0119 (UTC) FILETIME=[A83D6EF0:01C77171] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1275; t=1175111145; x=1175975145; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20Comments=20on=20-01=20re=3A=20nomenclature |Sender:=20; bh=UaNiugTylKJfuuR5mY6HMqTSghahqjrLRmp7YqiDeyY=; b=e6SdnAp/8b5zP5cUmGQ6LAts9Js9fAt7RTilb8zeFtMekQ9p/JzSv8dpbozGfxdUjcbylysW VNGiq2DHcbcnoeo7sw3tCFzlww1dgMnoABBsdXRq02aKRU5JgofOOzQQ; Authentication-Results: sj-dkim-3; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Paul, Please find my reply inline. > >I think we can agree to disagree on this point however I don't think=20 >our disagreement impacts the NEA protocol requirements. I fully disagree. What Alan is asking for is to collapse Posture Attributes with Policy Attributes; I agree with his request and his logic. I have not seen a concrete example of a Policy Attribute that does not have an identical analog in a Posture Attribute. For every "I am going to want X&Y&Z" or "I demand X&Y&Z", there is an equivalent "I do X&Y&Z". If someone can show me a Policy Attribute that doesn't have an analog Posture Attribute, it would help me resolve this issue. =20 The disagreement I was referring to was whether we need the ability to pass and evaluate expressions in a vendor specific fashion during assessment or all of that can be done during remediation. I think Paul Sangster started a separate thread requesting for WG input whether we should be moving to a flat attribute space instead of typing attributes into posture, policy, result etc. Can I infer that you favor a flat attribute space or is your comment specifically that we don't need to differentiate between posture and policy attributes. regards, kaushik _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 28 22:47: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 1HWkez-00081A-9o; Wed, 28 Mar 2007 22:46:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWkex-000806-Bg for nea@ietf.org; Wed, 28 Mar 2007 22:46:43 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWkeu-0001qa-Qa for nea@ietf.org; Wed, 28 Mar 2007 22:46:43 -0400 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 2C4AE38C5C8; Wed, 28 Mar 2007 19:46:40 -0700 (PDT) X-AuditID: d80ac287-91523bb000000c42-bd-460b2890d6a4 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 009BA348003; Wed, 28 Mar 2007 19:46:40 -0700 (PDT) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HWket-0006WT-Sr; Wed, 28 Mar 2007 19:46:39 -0700 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Mar 2007 19:46:11 -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: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) Date: Wed, 28 Mar 2007 19:46:10 -0700 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A0288E418@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) Thread-Index: AcdwG0EooT5iHsMaRqe+FWSugL8MqABZ/R4w References: <618694EF0B657246A4D55A97E38274C3033B18DF@xmb-sjc-22d.amer.cisco.com> From: "Paul Sangster" To: "Paul Hoffman" , X-OriginalArrivalTime: 29 Mar 2007 02:46:11.0239 (UTC) FILETIME=[68F29370:01C771AC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Changing the topic to a slightly different question again about the need for the policy attribute type (thus changing the subject ...) A similar general question is whether we wish to include the usage model where the client is trusted to perform policy compliance check and provide only the claimed result instead of actual posture information. This usage model was the genesis for policy and compliance claim attribute types (passing policy or references/search keywords to the endpoint instead of requests for posture.) We added this usage model in response to a dialog on the alias back in Nov/Dec where a WG member wanted a model where the endpoint did not send posture over the network. If the WG believes we do not want this model supported, I see no reason for the policy and compliance claim attribute types in the spec. However if we do want this usage, I don't yet understand the thought that the posture and policy attribute types are identical in syntax and semantics. We currently talk about policy attributes as being sent exclusively by the NEA server in order to solicit compliance claim attributes in response. I might envision the policies will list (at least) some form of components identifiers and their expected value ranges (=3D=3D,<,>,!=3D). Attribute in the policy attribute type might = also just list keywords or URI to guide the NEA Client to select the policies expected to be met (instead of including them in the PA messages.) =20 Attributes in the posture attribute type are sent only by the NEA Client in response to request attributes and would include component identifiers and actual values reflecting the system configuration. This might actually be a subset of the attribute space which falls in the policy attribute type space, but they have a different general semantic (e.g. firewall version is 1.2.3 vs. firewall version must be > 1.1). Maybe this would be less of a concern if we changed our class (think category) naming to message types instead of portions of the attribute space which would overlap. People seemed to be confused about the fact that its ok for particular attributes might exist in multiple categories (AKA attribute types). If we leave the naming we will make this more clear. Attribute types are a level of abstraction above the individual attribute level. We're not talking at that level in this I-D (that's another RFC we'll produce when we work on PA's contents.) Each attribute type (as they are currently) just describe the classes (or category based on role) of a portion of the attribute space. Its fine for us to define specific attributes that fall within each attribute type (they aren't intended to be proper subsets of the full attribute space just a name for talking generally about their role in the reference model). So a question for the WG: Do we want to document a usage model where the NEA Server sends "policy" to the NEA Client such that it can respond with only the client's claim of the results of the posture comparison with the "policy"? If no, this seems to allow Policy and Compliance Claim Attribute Types to be removed for the I-D. If yes, we'll need to resolve original thread. Paul > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 > Sent: Monday, March 26, 2007 6:56 AM > To: nea@ietf.org > Subject: RE: [Nea] Comments on -01 re: nomenclature >=20 > At 6:14 PM -0700 3/23/07, Kaushik Narayan \(kaushik\) wrote: > > > > > >I think we can agree to disagree on this point however I don't think=20 > >our disagreement impacts the NEA protocol requirements. >=20 > I fully disagree. What Alan is asking for is to collapse=20 > Posture Attributes with Policy Attributes; I agree with his=20 > request and his logic. I have not seen a concrete example of=20 > a Policy Attribute that does not have an identical analog in=20 > a Posture Attribute. For every "I am going to want X&Y&Z" or=20 > "I demand X&Y&Z", there is an equivalent "I do X&Y&Z". If=20 > someone can show me a Policy Attribute that doesn't have an=20 > analog Posture Attribute, it would help me resolve this issue. >=20 > On a separate topic, I agree with Alan that Overuse Of=20 > Capitalization makes the document harder to read. >=20 > --Paul Hoffman, Director > --VPN Consortium >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Mar 29 14:55: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 1HWzlt-0005Qo-27; Thu, 29 Mar 2007 14:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWzlr-0005Qb-S8 for nea@ietf.org; Thu, 29 Mar 2007 14:54:51 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWzlp-0004cg-3v for nea@ietf.org; Thu, 29 Mar 2007 14:54:51 -0400 Received: from [192.168.0.12] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by book.deployingradius.com (Postfix) with ESMTP id 15FD4A70B7 for ; Thu, 29 Mar 2007 11:54:31 -0700 (PDT) Message-ID: <460C0B62.9000902@deployingradius.com> Date: Thu, 29 Mar 2007 19:54:26 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nea@ietf.org Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) References: <618694EF0B657246A4D55A97E38274C3033B18DF@xmb-sjc-22d.amer.cisco.com> <5A58F967CBEBBB4A82DF126CF8A9596A0288E418@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A0288E418@SVL1XCHCLUPIN02.enterprise.veritas.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Paul Sangster wrote: > A similar general question is whether we wish to include the usage model > where the client is trusted to perform policy compliance check and > provide only the claimed result instead of actual posture information. The client is already doing that. If it reports that it's anti-virus software is at version X, you're already trusting it to report that correctly. You might was well trust it to run a complex policy, and report compliance with policy version X. > We added this usage model in response to a dialog on the alias back in > Nov/Dec where a WG member wanted a model where the endpoint did not send > posture over the network. If the WG believes we do not want this model > supported, I see no reason for the policy and compliance claim attribute > types in the spec. I think the use model there was to send *nothing* of posture information over the network. e.g. The client collects a bunch of opaque tokens from local anti-virus software (etc.), and sends them to the server. Anyone watching this exchange, including the client, has no information about what those tokens mean. Those tokens can have meaning to the anti-virus software on the client, and the corresponding product on the server side. There is no need for those tokens to have meaning for anyone else in the network. > However if we do want this usage, I don't yet understand the thought > that the posture and policy attribute types are identical in syntax and > semantics. We currently talk about policy attributes as being sent > exclusively by the NEA server in order to solicit compliance claim > attributes in response. I might envision the policies will list (at > least) some form of components identifiers and their expected value > ranges (==,<,>,!=). Many IETF WG's have devolved into endless discussions based on what people can "envision". Can we talk about practical use-cases, instead? With examples? My vision is this: The NEA server says that the client must comply with policy version X. That policy may include multiple sub-policies (e.g. one for each anti-virus product, etc.). Those sub-policies say the same thing, that the product must comply with policy X, subsection Y. The client either returns proof that it is compliant, or claims non-compliance (where no proof is necessary). To me, this model satisfies the NEA charter and requirements. It also means that the policy and posture attributes are the same: policy = "YOU MUST DO ..." attributes = "X, Y, Z" posture = "YES, I DO ..." attributes = "X, Y, Z" > Attribute in the policy attribute type might also > just list keywords or URI to guide the NEA Client to select the policies > expected to be met (instead of including them in the PA messages.) That presumes a certain use model. > Attributes in the posture attribute type are sent only by the NEA Client > in response to request attributes and would include component > identifiers and actual values reflecting the system configuration. While this would be simple, it's not strictly necessary. The protocol could include a CHAP-like system that proves both ends know the same values, without actually exchanging those values over the network. > This > might actually be a subset of the attribute space which falls in the > policy attribute type space, but they have a different general semantic > (e.g. firewall version is 1.2.3 vs. firewall version must be > 1.1). To use that exact example to prove my point: policy: firewall version must be > 1.1 posture: firewall version is > 1.1 Even with that example, I don't see a need to exchange *different* information. Why is the client returning "1.2.3" when the server asked for "> 1.1"? Why not just return "yes", or even "> 1.1"? > Maybe this would be less of a concern if we changed our class (think > category) naming to message types instead of portions of the attribute > space which would overlap. Yes. To re-iterate, DNS, DHCP, RADIUS, etc. all do this. They've done it for over a decade. It's common practice. > Attribute types are a level of abstraction above the individual > attribute level. We're not talking at that level in this I-D (that's > another RFC we'll produce when we work on PA's contents.) Each attribute > type (as they are currently) just describe the classes (or category > based on role) of a portion of the attribute space. Its fine for us to > define specific attributes that fall within each attribute type (they > aren't intended to be proper subsets of the full attribute space just a > name for talking generally about their role in the reference model). I'm not sure I understand that paragraph. > So a question for the WG: > > Do we want to document a usage model where the NEA Server sends "policy" > to the NEA Client such that it can respond with only the client's claim > of the results of the posture comparison with the "policy"? > > If no, this seems to allow Policy and Compliance Claim Attribute Types > to be removed for the I-D. > > If yes, we'll need to resolve original thread. I'm not sure the question targets the discussion. The discussion was about sending complex policies with conditional statements, which is unnecesary. Sending policy *requirements* like "prove you do X, Y, and Z" is a completely different story. Those requirements can be trivially described and encoded. Sending such requirements means that the policy and posture attributes become the same, but they're just carried in different messages. And there's no need for compliance claim attributes, because the posture attributes fulfill that role. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Mar 29 18:34:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3C7-0001Qp-3U; Thu, 29 Mar 2007 18:34:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3C6-0001Qk-Io for nea@ietf.org; Thu, 29 Mar 2007 18:34:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX3C5-00054X-7q for nea@ietf.org; Thu, 29 Mar 2007 18:34:10 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2TMY7io003882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Mar 2007 15:34:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <460C0B62.9000902@deployingradius.com> References: <618694EF0B657246A4D55A97E38274C3033B18DF@xmb-sjc-22d.amer.cisco.com> <5A58F967CBEBBB4A82DF126CF8A9596A0288E418@SVL1XCHCLUPIN02.enterprise.verit as.com> <460C0B62.9000902@deployingradius.com> Date: Thu, 29 Mar 2007 15:33:56 -0700 To: nea@ietf.org From: Paul Hoffman Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 At 7:54 PM +0100 3/29/07, Alan DeKok wrote: > My vision is this: The NEA server says that the client must comply >with policy version X. That policy may include multiple sub-policies >(e.g. one for each anti-virus product, etc.). Those sub-policies say >the same thing, that the product must comply with policy X, subsection Y. > > The client either returns proof that it is compliant, or claims >non-compliance (where no proof is necessary). To me, this model >satisfies the NEA charter and requirements. It also means that the >policy and posture attributes are the same: > > policy = "YOU MUST DO ..." > attributes = "X, Y, Z" > posture = "YES, I DO ..." > attributes = "X, Y, Z" At least Alan and I were thinking the same thing when we spoke at the mic last week. This is what I was thinking as well. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Mar 30 03:58: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 1HXC0S-0002EI-IA; Fri, 30 Mar 2007 03:58:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXC0Q-0002Bh-B9 for nea@ietf.org; Fri, 30 Mar 2007 03:58:42 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXC0O-0004yP-Gr for nea@ietf.org; Fri, 30 Mar 2007 03:58:42 -0400 Received: from [192.168.0.12] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by book.deployingradius.com (Postfix) with ESMTP id BB883A70B7; Fri, 30 Mar 2007 00:58:31 -0700 (PDT) Message-ID: <460CC323.9090600@deployingradius.com> Date: Fri, 30 Mar 2007 09:58:27 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Sangster , nea@ietf.org Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 re:nomenclature) References: <618694EF0B657246A4D55A97E38274C3033B18DF@xmb-sjc-22d.amer.cisco.com> <5A58F967CBEBBB4A82DF126CF8A9596A0288E418@SVL1XCHCLUPIN02.enterprise.veritas.com> <460BC8CE.9010005@deployingradius.com> <5A58F967CBEBBB4A82DF126CF8A9596A0288E654@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A0288E654@SVL1XCHCLUPIN02.enterprise.veritas.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 My original message was private to Paul, and he responded similarly. I'll respond publicly, to move the discussion back to a public forum. Paul Sangster wrote: [ re: opaque posture tokens] > Not sure I follow the "nothing" yet we're exchanging info over the > network. From who's perspective are we sending nothing? This sounds > like the collectors create posture tokens that get sent to the peer > validator who can also understand them. Parties in between don't need > to know what they contain. Yes. > Do you mean by "nothing" that the opaque tokens do not contain > information about the posture of the system? This sounds alittle bit > like the Assertion Attribute Type which I could see as a valid usage > model (one that NAP plans to support.) Yes and no. The tokens contain information that the validator can use to prove posture, but which no one else can use to determine posture. > I used that word because we haven't defined what policy attributes look > like yet and I'm personally not sure we need them unless there is a > usage model requiring them. I could propose a real world example but > would rather hear someone argue that we need this. My higher-layer question is this: Do we want to validate that the client satisfies the policy, or do we want to determine what the posture of the client is? Those are two very different questions. If the client satisfies the policy, the details of its exact posture do not matter. This simplifies the protocol and deployment scenarios. >> policy = "YOU MUST DO ..." >> attributes = "X, Y, Z" >> posture = "YES, I DO ..." >> attributes = "X, Y, Z" > > What your calling posture above is what the spec calls compliance claim > attribute type. Posture provides "proof" instead of making claims about > compliance to a particular policy. However your description sounds > about right for the policy/compliance claims exchange. I see what you mean. I'm curious to know what "proof" means in the context of lying endpoints. I suspect that the posture and compliance claim attributes collapse into one. > Correct and I'm hoping to find out if anyone cares about this usage > model. This example is interesting as it might allow for > pre-provisioned (or downloaded) policy which is indexed by keywords and > the NEA server just sends keywords indicating which policies need to be > met. This isn't really very different from your example just the syntax > changes. It's exactly the point I was trying to get across in earlier discussions. If the method you outline above is available, almost all of the NEA protocol can disappear. All that is needed is: server -> client : Comply with policy X client -> server : proof of compliance (or claim of compliance) ... >> policy: firewall version must be > 1.1 >> posture: firewall version is > 1.1 > > Again just a wording thing that "posture" is "complaince claim" > attribute type in the spec. I think the common understanding of posture is close to what the spec calls "compliance claim", and the common understanding of "proof of posture" is what the spec calls "posture". i.e. The posture of the client is independent of the policy. The client has a particular posture, and the purpose of NEA is to convince the network that the clients posture satisfies the policy. Everything else works towards that goal. Confusing "posture" with "proof" or "claim" results in complications. >... It sounds like you > believe we need to support the assertion attribute type model (e.g. > signed tokens asserting some compliance statements.) Do you think we > need to support the sending of policy to the client, or just the request > attribute type model ('tell me about your firewall configuration?')? I don't think we need request attributes. I don't think we need to send policy to the client. I think we just need to tell the client which policy to run. > But to comment on what you said I don't see how that solves the complex > policy problem. The "X" in your quote could be "your symantec firewall > must be > version 1.1" and "Y" could be "your symantec AV must be > running user-level rootkit protection with signatures newer than > 01/01/07". So I don't see how this eliminates conditional statements. > It might also be that "Y" is "OR you can run the windows firewall > version 0.5" allowing choice of firewall vendor/version. In case I haven't been clear, I would strenuously avoid *any* kind of conditional expressions in the NEA protocol. I believe that there are other methods of achieving the same result that are simpler and more robust. > If we drop policy attribute type we can also punt on policy expression > which is a big plus for moving forward. But if we need to provide an > interoperable way to download policy and policy is contained in the > standard attributes we are opening that box. How is downloading of policies different than downloading of any other software update? Experience shows that if we define conditional policy statements in the protocol, those conditions will quickly explode into a full-fledged language. Or, the discussions around the feature set of the language will never end. My conclusion, then, is that we should avoid such rat-holes, and discard any requirement to do conditional policies. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Mar 30 06:36:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXESo-0003S8-Kn; Fri, 30 Mar 2007 06:36:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXESn-0003S3-S6 for nea@ietf.org; Fri, 30 Mar 2007 06:36:09 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXESl-0006Ff-8d for nea@ietf.org; Fri, 30 Mar 2007 06:36:09 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11.20060308/8.13.8) with ESMTP id l2UAY44Z017600 for ; Fri, 30 Mar 2007 06:34:04 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2UAa6rQ202056 for ; Fri, 30 Mar 2007 04:36:06 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2UAa6vm009625 for ; Fri, 30 Mar 2007 04:36:06 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2UAa55V009610; Fri, 30 Mar 2007 04:36:05 -0600 In-Reply-To: Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) To: Paul Hoffman X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Fri, 30 Mar 2007 03:35:53 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 03/30/2007 04:36:05 MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1772930732==" Errors-To: nea-bounces@ietf.org --===============1772930732== Content-type: multipart/related; Boundary="0__=07BBF83DDFA98E518f9e8a93df938690918c07BBF83DDFA98E51" --0__=07BBF83DDFA98E518f9e8a93df938690918c07BBF83DDFA98E51 Content-type: multipart/alternative; Boundary="1__=07BBF83DDFA98E518f9e8a93df938690918c07BBF83DDFA98E51" --1__=07BBF83DDFA98E518f9e8a93df938690918c07BBF83DDFA98E51 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, IMHO there is no need for the server to inform the client of what= it "MUST" do. The client can simply report what it is doing and the server= can compare that against what it thinks the client must do, and make the admission decision on the server. Giving the client granular descriptions of what states must be me= t to attain access is a rather large security hole IMHO. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall = Paul Hoffman = = To nea@ietf.org = 03/29/2007 03:33 = cc PM = Subj= ect Re: Policy Attribute Type (split= from [Nea] Comments on -01 r= e: nomenclature) = = = = = = = At 7:54 PM +0100 3/29/07, Alan DeKok wrote: > My vision is this: The NEA server says that the client must comply= >with policy version X. That policy may include multiple sub-policies >(e.g. one for each anti-virus product, etc.). Those sub-policies say >the same thing, that the product must comply with policy X, subsection= Y. > > The client either returns proof that it is compliant, or claims >non-compliance (where no proof is necessary). To me, this model >satisfies the NEA charter and requirements. It also means that the >policy and posture attributes are the same: > > policy =3D "YOU MUST DO ..." > attributes =3D "X, Y, Z" > posture =3D "YES, I DO ..." > attributes =3D "X, Y, Z" At least Alan and I were thinking the same thing when we spoke at the mic last week. This is what I was thinking as well. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF83DDFA98E518f9e8a93df938690918c07BBF83DDFA98E51 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

IMHO there is no need for the server to inform the client of what it &= quot;MUST" do. The client can simply report what it is doing and t= he server can compare that against what it thinks the client must do, a= nd make the admission decision on the server.

Giving the client granular descriptions of what states must be met to = attain access is a rather large security hole IMHO.


Regards,
Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Global Technology Services
Security & Privacy Technology Integration Team

Second Life: Yehoo Newall

3D"InactivePaul Hoffman <paul.hoffman@vp= nc.org>


=
          Paul Hoffman <paul.hoffman@vpnc.org>

          03/29/2007 03:33 PM

 =
3D=
To
3D""
nea@ietf.org
3D=
cc
3D""
3D=
Subject
3D""
Re: Policy Attribute Type (split from [Nea] Comments o= n -01 re: nomenclature)
3D=3D""

At 7:54 PM +0100 3/29/07, Alan DeKok wrote:
>   My vision is this:  The NEA server says that the clien= t must comply
>with policy version X.  That policy may include multiple sub-p= olicies
>(e.g. one for each anti-virus product, etc.).  Those sub-polic= ies say
>the same thing, that the product must comply with policy X, subsect= ion Y.
>
>   The client either returns proof that it is compliant, or cl= aims
>non-compliance (where no proof is necessary).  To me, this mod= el
>satisfies the NEA charter and requirements.  It also means tha= t the
>policy and posture attributes are the same:
>
> policy =3D "YOU MUST DO ..."
> attributes =3D "X, Y, Z"
> posture =3D "YES, I DO ..."
> attributes =3D "X, Y, Z"

At least Alan and I were thinking the same thing when we spoke at the <= br> mic last week. This is what I was thinking as well.

--Paul Hoffman, Director
--VPN Consortium

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

= --1__=07BBF83DDFA98E518f9e8a93df938690918c07BBF83DDFA98E51-- --0__=07BBF83DDFA98E518f9e8a93df938690918c07BBF83DDFA98E51 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF83DDFA98E518f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF83DDFA98E518f9e8a93df938690918c07BBF83DDFA98E51 Content-type: image/gif; name="pic16732.gif" Content-Disposition: inline; filename="pic16732.gif" Content-ID: <2__=07BBF83DDFA98E518f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBF83DDFA98E518f9e8a93df938690918c07BBF83DDFA98E51 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF83DDFA98E518f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF83DDFA98E518f9e8a93df938690918c07BBF83DDFA98E51-- --===============1772930732== 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 --===============1772930732==-- From nea-bounces@ietf.org Fri Mar 30 08:49:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGXY-000268-Rb; Fri, 30 Mar 2007 08:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGXX-00022X-FX for nea@ietf.org; Fri, 30 Mar 2007 08:49:11 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXGXW-0005ar-0z for nea@ietf.org; Fri, 30 Mar 2007 08:49:11 -0400 Received: from [192.168.0.12] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by book.deployingradius.com (Postfix) with ESMTP id 03E1FA70B7; Fri, 30 Mar 2007 05:49:06 -0700 (PDT) Message-ID: <460D0739.7080608@deployingradius.com> Date: Fri, 30 Mar 2007 14:48:57 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: nea@ietf.org, Paul Hoffman 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 Frank Yeh Jr wrote: > IMHO there is no need for the server to inform the client of what it > "MUST" do. The client can simply report what it is doing and the server > can compare that against what it thinks the client must do, and make the > admission decision on the server. What information is the client supposed to report to the server? The extremes range from nearly nothing (IP / MAC / hostname), to sending its complete disk image. i.e. There has to be some method of bootstrapping the clients knowledge of what the server cares about. That information can be exchanged as part of NEA, or bootstrapped via some offline method. > Giving the client granular descriptions of what states must be met to > attain access is a rather large security hole IMHO. But the client already has that information. Anti-virus software includes lists of "bad" content. The client therefore knows that it must pretend to not have any of that "bad" content before gaining access. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Mar 30 09:51:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHVO-0002EY-AP; Fri, 30 Mar 2007 09:51:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHVL-0001vV-Kc for nea@ietf.org; Fri, 30 Mar 2007 09:50:59 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXHVC-0001k0-Db for nea@ietf.org; Fri, 30 Mar 2007 09:50:59 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2UDogvY056658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Mar 2007 06:50:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 30 Mar 2007 06:50:36 -0700 To: nea@ietf.org From: Paul Hoffman Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 At 3:35 AM -0700 3/30/07, Frank Yeh Jr wrote: > IMHO there is no need for the server to inform the client of >what it "MUST" do. The client can simply report what it is doing and >the server can compare that against what it thinks the client must >do, and make the admission decision on the server. Agree. But there is still a requirement that the server be able to inform the client what kind of information the server wants. Otherwise, we have the case that Alan describes where the client might have to send a ton of unneeded information. Stated another way, the requirements are: - Server MUST be able to send request for information to the client. - Server MUST accept whatever posture the client sends. - Client MAY send posture to the server without knowing what th server wants. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Mar 30 11:26:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXIzg-0002mi-Ie; Fri, 30 Mar 2007 11:26:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXIzf-0002lz-U4 for nea@ietf.org; Fri, 30 Mar 2007 11:26:24 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HXIzb-0001jD-1S for nea@ietf.org; Fri, 30 Mar 2007 11:26:23 -0400 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 54C7338C1DC; Fri, 30 Mar 2007 08:26:12 -0700 (PDT) X-AuditID: d80ac287-94e6abb000000c42-47-460d2c14df41 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 1E9C1348004; Fri, 30 Mar 2007 08:26:12 -0700 (PDT) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HXIzU-0002mc-09; Fri, 30 Mar 2007 08:26:12 -0700 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Mar 2007 08:26:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Policy Attribute Type (split from [Nea] Comments on -01 re:nomenclature) Date: Fri, 30 Mar 2007 08:26:05 -0700 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A028C9976@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Policy Attribute Type (split from [Nea] Comments on -01 re:nomenclature) Thread-Index: Acdyt4PP5KsfxNUJRkG3HzPnRUia4AAJ13Xw References: From: "Paul Sangster" To: "Frank Yeh Jr" X-OriginalArrivalTime: 30 Mar 2007 15:26:08.0697 (UTC) FILETIME=[BD904290:01C772DF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1303119580==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1303119580== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C772DF.BD40663A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C772DF.BD40663A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C772DF.BD40663A" ------_=_NextPart_002_01C772DF.BD40663A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This sounds like your preference is to only support the Request and Posture Attribute Types usage model and to not include the Policy and Compliance Claim Attribute Types (don't send policy to the client and ask it to claim whether it meets the policy.) =20 Do others feel the same about this? ________________________________ From: Frank Yeh Jr [mailto:fyeh@us.ibm.com]=20 Sent: Friday, March 30, 2007 3:36 AM To: Paul Hoffman Cc: nea@ietf.org Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 re:nomenclature) =09 =09 Greetings, =09 IMHO there is no need for the server to inform the client of what it "MUST" do. The client can simply report what it is doing and the server can compare that against what it thinks the client must do, and make the admission decision on the server. =09 Giving the client granular descriptions of what states must be met to attain access is a rather large security hole IMHO.=20 =09 =09 Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team =09 Second Life: Yehoo Newall =09 Paul Hoffman =09 =09 =09 Paul Hoffman =20 03/29/2007 03:33 PM =20 To nea@ietf.org=09 cc =09 Subject Re: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature)=09 =09 At 7:54 PM +0100 3/29/07, Alan DeKok wrote: > My vision is this: The NEA server says that the client must comply >with policy version X. That policy may include multiple sub-policies >(e.g. one for each anti-virus product, etc.). Those sub-policies say >the same thing, that the product must comply with policy X, subsection Y. > > The client either returns proof that it is compliant, or claims >non-compliance (where no proof is necessary). To me, this model >satisfies the NEA charter and requirements. It also means that the >policy and posture attributes are the same: > > policy =3D "YOU MUST DO ..." > attributes =3D "X, Y, Z" > posture =3D "YES, I DO ..." > attributes =3D "X, Y, Z" =09 At least Alan and I were thinking the same thing when we spoke at the=20 mic last week. This is what I was thinking as well. =09 --Paul Hoffman, Director --VPN Consortium =09 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea =09 =09 ------_=_NextPart_002_01C772DF.BD40663A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This sounds like your preference is to only = support=20 the Request and Posture Attribute Types usage model and = to not=20 include the Policy and Compliance Claim Attribute Types (don't = send=20 policy to the client and ask it to claim whether it meets the=20 policy.)
 
Do others feel the same about = this?

From: Frank Yeh Jr = [mailto:fyeh@us.ibm.com]=20
Sent: Friday, March 30, 2007 3:36 AM
To: Paul=20 Hoffman
Cc: nea@ietf.org
Subject: Re: Policy = Attribute=20 Type (split from [Nea] Comments on -01 = re:nomenclature)

Greetings,

IMHO there is no need for the server to inform = the client=20 of what it "MUST" do. The client can simply report what it is doing = and the=20 server can compare that against what it thinks the client must do, and = make=20 the admission decision on the server.

Giving the client = granular=20 descriptions of what states must be met to attain access is a rather = large=20 security hole IMHO.


Regards,
Frank Yeh
Sr. Security = &=20 Privacy Integration Architect
IBM Global Technology = Services
Security=20 & Privacy Technology Integration Team

Second Life: Yehoo=20 Newall

3D"Inactive" = src=3D"cid:763591915@30032007-1D18" width=3D16 border=3D0>Paul Hoffman = <paul.hoffman@vpnc.org>


          Paul Hoffman=20 <paul.hoffman@vpnc.org> =

          03/29/2007 03:33 = PM

3D""=20
To
 3D""=20
nea@ietf.org
3D""=20
cc
 3D""=20
3D""=20
Subject
 3D""=20
Re: Policy Attribute Type (split from [Nea] = Comments on -01=20 re: nomenclature)
3D""=20 3D""=20

At= 7:54=20 PM +0100 3/29/07, Alan DeKok wrote:
>   My vision is this:=20  The NEA server says that the client must comply
>with = policy=20 version X.  That policy may include multiple = sub-policies
>(e.g.=20 one for each anti-virus product, etc.).  Those sub-policies=20 say
>the same thing, that the product must comply with policy X, = subsection Y.
>
>   The client either returns proof = that it=20 is compliant, or claims
>non-compliance (where no proof is = necessary).=20  To me, this model
>satisfies the NEA charter and = requirements.=20  It also means that the
>policy and posture attributes are = the=20 same:
>
> policy =3D "YOU MUST DO ..."
> attributes = =3D "X, Y,=20 Z"
> posture =3D "YES, I DO ..."
> attributes =3D "X, Y, = Z"

At=20 least Alan and I were thinking the same thing when we spoke at the =
mic=20 last week. This is what I was thinking as well.

--Paul Hoffman, = Director
--VPN=20 = Consortium

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

------_=_NextPart_002_01C772DF.BD40663A-- ------_=_NextPart_001_01C772DF.BD40663A Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <763591915@30032007-1D18> Content-Description: graycol.gif Content-Location: graycol.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01C772DF.BD40663A Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <763591915@30032007-1D1F> Content-Description: ecblank.gif Content-Location: ecblank.gif R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------_=_NextPart_001_01C772DF.BD40663A-- --===============1303119580== 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 --===============1303119580==-- From nea-bounces@ietf.org Fri Mar 30 11:31:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJ4E-0006KY-9S; Fri, 30 Mar 2007 11:31:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJ4D-0006KT-7P for nea@ietf.org; Fri, 30 Mar 2007 11:31:05 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJ4A-0000HQ-P7 for nea@ietf.org; Fri, 30 Mar 2007 11:31:05 -0400 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 5858A38C2E3; Fri, 30 Mar 2007 08:31:02 -0700 (PDT) X-AuditID: d80ac287-93326bb000000c42-e3-460d2d36e1bf Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 1EB71348002; Fri, 30 Mar 2007 08:31:02 -0700 (PDT) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HXJ4A-0000x4-0f; Fri, 30 Mar 2007 08:31:02 -0700 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Mar 2007 08:30:59 -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: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) Date: Fri, 30 Mar 2007 08:30:56 -0700 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A028C9985@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) Thread-Index: Acdy0qD+8ntB9u2hQi+Qn2t5SVrF+wADSsvg References: From: "Paul Sangster" To: "Paul Hoffman" , X-OriginalArrivalTime: 30 Mar 2007 15:30:59.0619 (UTC) FILETIME=[6AF76F30:01C772E0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.6 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 > Sent: Friday, March 30, 2007 6:51 AM > To: nea@ietf.org > Subject: Re: Policy Attribute Type (split from [Nea] Comments=20 > on -01 re: nomenclature) >=20 > At 3:35 AM -0700 3/30/07, Frank Yeh Jr wrote: > > IMHO there is no need for the server to inform the=20 > client of what it=20 > >"MUST" do. The client can simply report what it is doing and=20 > the server=20 > >can compare that against what it thinks the client must do, and make=20 > >the admission decision on the server. >=20 > Agree. But there is still a requirement that the server be=20 > able to inform the client what kind of information the server wants.=20 This is the purpose of the Request Attribute Type (defines what the server needs to perform the compliance comparison.) =20 So it sound like you would also like to not include the Policy and Compliance Claim Attribute Type model (send policy to client and ask it if it is compliant)? > Otherwise, we have the case that Alan describes where the=20 > client might have to send a ton of unneeded information. Agreed (this topic is discussed in the privacy considerations section in hopes of causing some WG discussion.) This model seems inefficient and not privacy sensitive. >=20 > Stated another way, the requirements are: >=20 > - Server MUST be able to send request for information to the client. >=20 > - Server MUST accept whatever posture the client sends. >=20 > - Client MAY send posture to the server without knowing what=20 > th server wants. Sounds reasonable although I wonder if we even need the last one (fodder for group discussion). Since it's just a MAY this seems acceptable. >=20 > --Paul Hoffman, Director > --VPN Consortium >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Mar 30 11:33:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJ6V-00011Q-8Z; Fri, 30 Mar 2007 11:33:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJ6U-00011L-Fs for nea@ietf.org; Fri, 30 Mar 2007 11:33:26 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HXJ6S-0002PO-Ox for nea@ietf.org; Fri, 30 Mar 2007 11:33:26 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11.20060308/8.13.8) with ESMTP id l2UFVKMD005604 for ; Fri, 30 Mar 2007 11:31:20 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2UFXNwl197964 for ; Fri, 30 Mar 2007 09:33:23 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2UFXMkv021046 for ; Fri, 30 Mar 2007 09:33:23 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2UFXMpu021016; Fri, 30 Mar 2007 09:33:22 -0600 In-Reply-To: Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) To: Paul Hoffman , Alan DeKok X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Fri, 30 Mar 2007 08:33:10 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 03/30/2007 09:33:22 MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0205688288==" Errors-To: nea-bounces@ietf.org --===============0205688288== Content-type: multipart/related; Boundary="0__=07BBF83DDFC7A9C88f9e8a93df938690918c07BBF83DDFC7A9C8" --0__=07BBF83DDFC7A9C88f9e8a93df938690918c07BBF83DDFC7A9C8 Content-type: multipart/alternative; Boundary="1__=07BBF83DDFC7A9C88f9e8a93df938690918c07BBF83DDFC7A9C8" --1__=07BBF83DDFC7A9C88f9e8a93df938690918c07BBF83DDFC7A9C8 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Sorry for the confusion_ I just read my previous email and I don'= t even understand it! What I meant to say was that I think the server should be able to= ask the client for the information it wants but it does not necessarily hav= e to tell the client what the required values are for any attribute. EG What= are the antivirus S/W release level and def file date? The server than comp= ares the returned values against the required ones and makes the decision. T= his model is probably most straightforward but it will generate the most network traffic. If we allow the client to know what the required values are for t= he attributes in question, then the client really should not have to send = back any state information at all, just a binary compliance state. EG Is the= A/V release level equal to 3.1 and the def file date > 01/01/07, to which t= he client basically replies with a yes or no. This model is not a straightforward as it allows the client to simply report compliance to = gain entrance. It is more scaleable across constrained network links and pla= ces less load on the server, but it requires a higher level of Trust in the= client stack. So something like the TCG's Trusted Computing Model would= have to be used to provide confidence that the client was not tampered with. I don't think there are any other models that make sense. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall = Paul Hoffman = = To nea@ietf.org = 03/30/2007 06:50 = cc AM = Subj= ect Re: Policy Attribute Type (split= from [Nea] Comments on -01 r= e: nomenclature) = = = = = = = At 3:35 AM -0700 3/30/07, Frank Yeh Jr wrote: > IMHO there is no need for the server to inform the client = of >what it "MUST" do. The client can simply report what it is doing and >the server can compare that against what it thinks the client must >do, and make the admission decision on the server. Agree. But there is still a requirement that the server be able to inform the client what kind of information the server wants. Otherwise, we have the case that Alan describes where the client might have to send a ton of unneeded information. Stated another way, the requirements are: - Server MUST be able to send request for information to the client. - Server MUST accept whatever posture the client sends. - Client MAY send posture to the server without knowing what th server wants. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF83DDFC7A9C88f9e8a93df938690918c07BBF83DDFC7A9C8 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Sorry for the confusion_ I just read my previous email and I don't eve= n understand it!

What I meant to say was that I think the server should be able to ask = the client for the information it wants but it does not necessarily hav= e to tell the client what the required values are for any attribute. EG= What are the antivirus S/W release level and def file date? The server= than compares the returned values against the required ones and makes = the decision. This model is probably most straightforward but it will g= enerate the most network traffic.

If we allow the client to know what the required values are for the at= tributes in question, then the client really should not have to send ba= ck any state information at all, just a binary compliance state. EG Is = the A/V release level equal to 3.1 and the def file date > 01/01/07,= to which the client basically replies with a yes or no. This model is = not a straightforward as it allows the client to simply report complian= ce to gain entrance. It is more scaleable across constrained network li= nks and places less load on the server, but it requires a higher level = of Trust in the client stack. So something like the TCG's Trusted Compu= ting Model would have to be used to provide confidence that the client = was not tampered with.

I don't think there are any other models that make sense.

Regards,
Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Global Technology Services
Security & Privacy Technology Integration Team

Second Life: Yehoo Newall

3D"InactivePaul Hoffman <paul.hoffman@vp= nc.org>


=
          Paul Hoffman <paul.hoffman@vpnc.org>

          03/30/2007 06:50 AM

 =
3D=
To
3D""
nea@ietf.org
3D=
cc
3D""
3D=
Subject
3D""
Re: Policy Attribute Type (split from [Nea] Comments o= n -01 re: nomenclature)
3D=3D""

At 3:35 AM -0700 3/30/07, Frank Yeh Jr wrote:
> IMHO there is no need for the server to inform the client of >what it "MUST" do. The client can simply report what it i= s doing and
>the server can compare that against what it thinks the client must =
>do, and make the admission decision on the server.

Agree. But there is still a requirement that the server be able to
= inform the client what kind of information the server wants.
Otherwise, we have the case that Alan describes where the client
might have to send a ton of unneeded information.

Stated another way, the requirements are:

- Server MUST be able to send request for information to the client.
- Server MUST accept whatever posture the client sends.

- Client MAY send posture to the server without knowing what th server = wants.

--Paul Hoffman, Director
--VPN Consortium

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

= --1__=07BBF83DDFC7A9C88f9e8a93df938690918c07BBF83DDFC7A9C8-- --0__=07BBF83DDFC7A9C88f9e8a93df938690918c07BBF83DDFC7A9C8 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF83DDFC7A9C88f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF83DDFC7A9C88f9e8a93df938690918c07BBF83DDFC7A9C8 Content-type: image/gif; name="pic26044.gif" Content-Disposition: inline; filename="pic26044.gif" Content-ID: <2__=07BBF83DDFC7A9C88f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBF83DDFC7A9C88f9e8a93df938690918c07BBF83DDFC7A9C8 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF83DDFC7A9C88f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF83DDFC7A9C88f9e8a93df938690918c07BBF83DDFC7A9C8-- --===============0205688288== 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 --===============0205688288==-- From nea-bounces@ietf.org Fri Mar 30 12:08:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJeB-0007cN-Cl; Fri, 30 Mar 2007 12:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJeA-0007cI-S3 for nea@ietf.org; Fri, 30 Mar 2007 12:08:14 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJe8-0005z4-3T for nea@ietf.org; Fri, 30 Mar 2007 12:08:14 -0400 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 18BFA38C16C; Fri, 30 Mar 2007 09:08:11 -0700 (PDT) X-AuditID: d80ac287-92925bb000000c42-7a-460d35ea8c7e Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id DC4EE348004; Fri, 30 Mar 2007 09:08:10 -0700 (PDT) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HXJe5-0007S7-Vk; Fri, 30 Mar 2007 09:08:10 -0700 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Mar 2007 09:07:36 -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: Policy Attribute Type (split from [Nea] Comments on -01 re:nomenclature) Date: Fri, 30 Mar 2007 09:07:32 -0700 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A028C99F2@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <460D0739.7080608@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Policy Attribute Type (split from [Nea] Comments on -01 re:nomenclature) Thread-Index: AcdyyhyJ0mz9RermQpmP37hKdx3dtAAGI8Sw References: <460D0739.7080608@deployingradius.com> From: "Paul Sangster" To: "Alan DeKok" X-OriginalArrivalTime: 30 Mar 2007 16:07:36.0141 (UTC) FILETIME=[883217D0:01C772E5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.6 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Friday, March 30, 2007 5:49 AM > To: Frank Yeh Jr > Cc: nea@ietf.org; Paul Hoffman > Subject: Re: Policy Attribute Type (split from [Nea] Comments=20 > on -01 re:nomenclature) >=20 > Frank Yeh Jr wrote: > > IMHO there is no need for the server to inform the client=20 > of what it=20 > > "MUST" do. The client can simply report what it is doing and the=20 > > server can compare that against what it thinks the client=20 > must do, and=20 > > make the admission decision on the server. >=20 > What information is the client supposed to report to the=20 > server? The extremes range from nearly nothing (IP / MAC /=20 > hostname), to sending its complete disk image. >=20 > i.e. There has to be some method of bootstrapping the=20 > clients knowledge of what the server cares about. The server could ask the client for component information it cares about (using attributes of the Request Attribute Type.) >=20 > That information can be exchanged as part of NEA, or=20 > bootstrapped via some offline method. Yes, the group could decide to support a model where in effect the request attributes are pre-provisioned on the endpoint or we could just say the server requests what it needs each time. >=20 > > Giving the client granular descriptions of what states must=20 > be met to=20 > > attain access is a rather large security hole IMHO. >=20 > But the client already has that information. Anti-virus=20 > software includes lists of "bad" content. The client=20 I presume your refering to the AV product specific policy defs which define "signatures" the AV uses to recognize "bad" content. Not sure this is useful for anything outside the AV product. > therefore knows that it must pretend to not have any of that=20 > "bad" content before gaining access. I think his point was not wanting to trust the client to manage (keep up to date), protect and properly report compliance to an enterprise's policy. This adds more complexity to the NEA Client which increases the likelihood for bugs, vulnerabilities, ... Also, not sending to the client requests including both: "what is the version of the XYZ component" and "i'm looking for an answer of 1.0" which makes it trivial to write a non-cooperating NEA Client that just repeats the desired answers instead of reporting its current posture information. If we stay out of expressing the expected result (compliance policy) then we can avoid the complexity of policy expression and how we make that interoperable. This seems helpful but at the cost of always sending posture information across the network (unless a prior assertion can be re-used which is a different usage model.) >=20 > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Mar 30 12:15:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJko-0003vB-Jj; Fri, 30 Mar 2007 12:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJko-0003v0-4T for nea@ietf.org; Fri, 30 Mar 2007 12:15:06 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJjE-0007N8-M8 for nea@ietf.org; Fri, 30 Mar 2007 12:13:32 -0400 Received: from [192.168.0.12] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by book.deployingradius.com (Postfix) with ESMTP id 04D8E11A572; Fri, 30 Mar 2007 09:13:22 -0700 (PDT) Message-ID: <460D3718.5@deployingradius.com> Date: Fri, 30 Mar 2007 18:13:12 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 re: nomenclature) References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nea@ietf.org, Paul Hoffman 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 Frank Yeh Jr wrote: > What I meant to say was that I think the server should be able to ask > the client for the information it wants but it does not necessarily have > to tell the client what the required values are for any attribute. EG > What are the antivirus S/W release level and def file date? The server > than compares the returned values against the required ones and makes > the decision. This model is probably most straightforward but it will > generate the most network traffic. Even that has privacy implications. > If we allow the client to know what the required values are for the > attributes in question, then the client really should not have to send > back any state information at all, just a binary compliance state. Some level of proof would be better than just a blind compliance claim. e.g. a challenge/response method that proves the client knows about a particular A/V release. > ... It is more scaleable across constrained network links and > places less load on the server, but it requires a higher level of Trust > in the client stack. So something like the TCG's Trusted Computing Model > would have to be used to provide confidence that the client was not > tampered with. I'm not familiar with that, so I'll have to look into it. I think it's easy to prove that the client has a copy of a particular piece of software. It's more difficult to prove that the client is running the software. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Mar 30 12:19: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 1HXJoQ-0006yQ-3j; Fri, 30 Mar 2007 12:18:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJoO-0006qe-Fc for nea@ietf.org; Fri, 30 Mar 2007 12:18:48 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJoM-00008J-Ab for nea@ietf.org; Fri, 30 Mar 2007 12:18:48 -0400 Received: from [192.168.0.12] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by book.deployingradius.com (Postfix) with ESMTP id 83E8011A572; Fri, 30 Mar 2007 09:18:43 -0700 (PDT) Message-ID: <460D385A.40108@deployingradius.com> Date: Fri, 30 Mar 2007 18:18:34 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Sangster Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01 re:nomenclature) References: <460D0739.7080608@deployingradius.com> <5A58F967CBEBBB4A82DF126CF8A9596A028C99F2@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A028C99F2@SVL1XCHCLUPIN02.enterprise.veritas.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Paul Sangster wrote: ... >> But the client already has that information. Anti-virus >> software includes lists of "bad" content. The client > > I presume your refering to the AV product specific policy defs which > define "signatures" the AV uses to recognize "bad" content. Not sure > this is useful for anything outside the AV product. It's still an example of policy that is known by the client. > I think his point was not wanting to trust the client to manage (keep up > to date), protect and properly report compliance to an enterprise's > policy. This adds more complexity to the NEA Client which increases the > likelihood for bugs, vulnerabilities, Yes. But any complex policy is just... running more software. We already have a model where the client downloads & runs software (A/V, OS updates, etc.). What's the cost of one more download? > ... Also, not sending to the > client requests including both: "what is the version of the XYZ > component" and "i'm looking for an answer of 1.0" which makes it trivial > to write a non-cooperating NEA Client that just repeats the desired > answers instead of reporting its current posture information. Yes. > If we stay out of expressing the expected result (compliance policy) > then we can avoid the complexity of policy expression and how we make > that interoperable. This seems helpful but at the cost of always > sending posture information across the network (unless a prior assertion > can be re-used which is a different usage model.) Yes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea