From nea-bounces@ietf.org Thu Oct 25 15:52: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 1Il8jR-0002kB-0m; Thu, 25 Oct 2007 15:51:05 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1Il8jP-0002in-Ts for nea-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 15:51:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8jP-0002hc-IO for nea@ietf.org; Thu, 25 Oct 2007 15:51:03 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il8jL-000465-74 for nea@ietf.org; Thu, 25 Oct 2007 15:51:00 -0400 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by extu-mxob-2.symantec.com (8.14.1/8.14.1) with ESMTP id l9PJoujK019641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Oct 2007 12:50:56 -0700 Received: from reserved-155-64-230-20.ges.symantec.com ([155.64.230.20] helo=TUS1XCHECNPIN03.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1Il8jI-0000GN-Cl for nea@ietf.org; Thu, 25 Oct 2007 12:50:56 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 12:50:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Oct 2007 12:50:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PA Security Proposal Thread-Index: AcfwzTq2XBTSVc2lRlGEdm6kXscoXwG9SksAB94C+cA= From: "Paul Sangster" To: X-OriginalArrivalTime: 25 Oct 2007 19:50:56.0256 (UTC) FILETIME=[5B9F2000:01C81740] X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Subject: [Nea] PA Security Proposal 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="===============0300071723==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0300071723== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81740.5B6603DB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81740.5B6603DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The design team has been working towards submitting a -05 version of the I-D next week. Our hope was this version would be ready for WGLC by early Nov (prior to IETF 70). Several folks have commented that they felt that the MUST requirement for PA security in PA-5 (see message below) was too strong and should be lowered to SHOULD or MAY. After some comments on the alias and discussions in the design team, we would like to propose the wording of PA-5 be changed from a MUST to a SHOULD to help reflect the broader positions of WG members while still stating the WG preference for PA candidate protocols providing authentication, integrity and confidentiality protection. =20 Just a reminder that these requirements will be used by the WG when evaluating and selecting candidate NEA protocols. The change of PA-5 from MUST to SHOULD allows the WG some room to evaluate and potentially select a candidate PA protocol that offers a subset or no PA security while continuing to emphasize the WG preference for PA security protections. Such flexibility should be beneficial during the WG evaluations of candidate PA protocols. This would enable us to better understand the impact on the PA protocol by including security protections and allow for alternative countermeasures to be considered (e.g. protection offered inside particular attributes). =20 In order for the design team to stay on schedule, we ask that the WG raise any objections to this approach ASAP so we can close discussions by 5PM PDT on Tues, Oct 30th and prepare the draft for submission the following day. =20 Thanks, =20 Paul ________________________________ From: Paul Sangster=20 Sent: Thursday, September 06, 2007 2:31 PM To: nea@ietf.org Subject: Should we downgrade PA security to a SHOULD, MAY or remove it? =09 =09 Hopefully everyone noticed that our -04 revision was published and is=20 awaiting comments from the WG. As mentioned in my prior e-mail on 8/24/07, we've made a significant number of changes based on comments received=20 during WGLC. We tried to address those comments but one significant question that was not addressed relates to our requirement PA-5 below: =20 "PA-5 The PA protocol MUST provide authentication, integrity, and=20 confidentiality of attributes communicated between a Posture=20 Collector and Posture Validator. This enables end-to-end security=20 across a NEA deployment that might involve traversal of several=20 systems." =20 The question is should this requirement be a SHOULD, MAY, or removed=20 entirely? This requirement guides our selection process for the PA protocol and currently would prevent candidate PA protocols from being selected if they lack proper security protections. In the past we've discussed the overlapping requirements for security upon PA (MUST), PB (MAY) and PT (MUST) and in Prague this factored into our decision to reduce PB to a MAY (instead of a MUST). This topic is also discussed in=20 section 8.2 and other parts of the spec. =20 The current PA security protections were included to provide for end to end=20 (e.g. Posture Collector to Posture Validator) authentication, integrity and confidentiality protection of the PA attributes. These attributes might travel to remote=20 systems hosting the posture validator that are separate from the posture=20 transport server thus PT protections are no longer present. Several folks=20 have mentioned that the protection of the link between the posture transport=20 server and remote posture validator could be provided in other less complex=20 ways and so requiring a standards based PA security protocol isn't critical=20 and will just make our deliverable more difficult. We also would need to specify a solution consistent with the principals of RFC 4107 which could be challenging. =20 We would like to request that the working group discuss whether we should=20 downgrade PA-5 to SHOULD, MAY or remove it all together. In order to bound the discussion we would like to conclude the discussion by 10PM PDT on thursday, Sept 20th (2 weeks). This will allows the editors time to make=20 any revisions to the specification and re-submit in a timely manner so we can product a new I-D ready for a re-start the WGLC process. =20 Paul ------_=_NextPart_001_01C81740.5B6603DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The design team has been working towards = submitting a=20 -05 version of the I-D next week.  Our hope was this version would = be ready=20 for WGLC by early Nov (prior to IETF 70).  Several folks = have=20 commented that they felt that the MUST requirement for PA = security in=20 PA-5 (see message below) was too strong and should be lowered to SHOULD = or=20 MAY.  After some comments on the alias and discussions in the = design team,=20 we would like to propose the wording of PA-5 be changed from a MUST to a = SHOULD=20 to help reflect the broader positions of WG members while = still=20 stating the WG preference for PA candidate protocols providing = authentication, integrity and confidentiality=20 protection.
 
Just a reminder that these requirements will = be used by=20 the WG when evaluating and selecting candidate NEA protocols.  The = change=20 of PA-5 from MUST to SHOULD allows the WG some room to evaluate and = potentially=20 select a candidate PA protocol that offers a subset or no PA = security=20 while continuing to emphasize the WG preference for PA security=20 protections.  Such flexibility should be beneficial during the WG=20 evaluations of candidate PA protocols.  This would enable us to = better=20 understand the impact on the PA protocol by including security = protections and=20 allow for alternative countermeasures to be considered (e.g. protection = offered=20 inside particular attributes).
 
In order for the design team to stay on = schedule, we=20 ask that the WG raise any objections to this approach ASAP so we = can close=20 discussions by 5PM PDT on Tues, Oct 30th and prepare the draft = for=20 submission the following day.
 
Thanks,
 
Paul

From: Paul Sangster =
Sent:=20 Thursday, September 06, 2007 2:31 PM
To:=20 nea@ietf.org
Subject: Should we downgrade PA security to a = SHOULD,=20 MAY or remove it?

Hopefully everyone noticed that our = -04=20 revision was published and is
awaiting comments from the = WG.  As=20 mentioned in my prior e-mail on 8/24/07,
we've made a significant = number=20 of changes based on comments received
during WGLC.  We = tried to=20 address those comments but one significant
question that was not=20 addressed relates to our requirement PA-5 below:
 
 "PA-5 The PA protocol MUST = provide=20 authentication, integrity, and =
      =20 confidentiality of attributes communicated between a Posture=20
       Collector and Posture = Validator.=20 This enables end-to-end security =
      =20 across a NEA deployment that might involve traversal of several=20
       systems."
 
The question is should this = requirement be a=20 SHOULD, MAY, or removed
entirely?  This requirement guides = our=20 selection process for the PA
protocol and currently would prevent = candidate PA protocols from being
selected if they lack proper = security=20 protections.  In the past
we've discussed the overlapping=20 requirements for security upon PA (MUST),
PB (MAY) and PT (MUST) = and in=20 Prague this factored into our decision to
reduce PB to a MAY = (instead of=20 a MUST).  This topic is also discussed in
section 8.2 and = other=20 parts of the spec.
 
The current PA security protections = were=20 included to provide for end to end
(e.g. Posture Collector to = Posture=20 Validator) authentication, integrity and
confidentiality protection of the = PA=20 attributes.  These=20 attributes might travel to remote
systems hosting = the=20 posture validator that are separate from the posture
transport = server=20 thus PT protections are no longer present.  Several folks =
have=20 mentioned that the protection of the link between the posture = transport=20
server and remote posture validator could be provided in other = less=20 complex
ways and so requiring a standards based PA security = protocol=20 isn't critical
and will just make our deliverable more = difficult. =20 We also would need to
specify a solution consistent with the = principals=20 of RFC 4107 which could
be challenging.
 
We would like to request that the = working group=20 discuss whether we should
downgrade PA-5 to SHOULD, MAY or = remove it all=20 together.  In order
to bound the discussion we would like to = conclude the discussion by 10PM PDT
on thursday, Sept 20th (2=20 weeks).  This will allows the editors time to make
any = revisions to=20 the specification and re-submit in a timely manner so we = can
product a new I-D ready for a = re-start the=20 WGLC process.
 
Paul
------_=_NextPart_001_01C81740.5B6603DB-- --===============0300071723== 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 --===============0300071723==-- From nea-bounces@ietf.org Fri Oct 26 16:13:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlVWi-0000Jq-Sn; Fri, 26 Oct 2007 16:11:28 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IlVWf-0000J3-M0 for nea-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 16:11:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlVWf-0000Iu-AO for nea@ietf.org; Fri, 26 Oct 2007 16:11:25 -0400 Received: from mail.sonicwall.com ([67.115.118.12] helo=es8000.sonicwall.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlVWe-0006A1-QX for nea@ietf.org; Fri, 26 Oct 2007 16:11:25 -0400 Received: from es8000.sonicwall.com (127.0.0.1) by es8000.sonicwall.com (MlfMTA v3.2r9) id h493r60171sp for ; Fri, 26 Oct 2007 13:01:54 -0700 (envelope-from ) Received: from us0exf01.us.sonicwall.com ([10.50.128.221]) by es8000.sonicwall.com (SonicWALL 6.0.1.9159) with ESMTP; Fri, 26 Oct 2007 13:01:54 -0700 Received: from us0exb10.us.sonicwall.com ([192.168.157.202]) by us0exf01.us.sonicwall.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Oct 2007 13:11:24 -0700 Received: from 192.168.161.190 ([192.168.161.190]) by us0exb10.us.sonicwall.com ([192.168.157.202]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Oct 2007 20:11:23 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 26 Oct 2007 13:11:20 -0700 Subject: Re: [Nea] PA Security Proposal From: Gary Tomlinson To: Message-ID: Thread-Topic: [Nea] PA Security Proposal Thread-Index: AcgYDF9xnceLEoP/Edy3twAbY6BmHA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 20:11:24.0040 (UTC) FILETIME=[61D9D880:01C8180C] X-Mlf-Version: 6.0.1.9159 X-Mlf-UniqueId: o200710262001540048587 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 concur with this proposal. It makes sense to me for the PA design team to explore the alternatives and produce a PA protocol that strikes the proper use case reach versus ROI balance. Gary On Thu, 25 Oct 2007 12:50:22 -0700 wrote: > The design team has been working towards submitting a -05 version of the > I-D next week. Our hope was this version would be ready for WGLC by > early Nov (prior to IETF 70). Several folks have commented that they > felt that the MUST requirement for PA security in PA-5 (see message > below) was too strong and should be lowered to SHOULD or MAY. After > some comments on the alias and discussions in the design team, we would > like to propose the wording of PA-5 be changed from a MUST to a SHOULD > to help reflect the broader positions of WG members while still stating > the WG preference for PA candidate protocols providing authentication, > integrity and confidentiality protection. > > Just a reminder that these requirements will be used by the WG when > evaluating and selecting candidate NEA protocols. The change of PA-5 > from MUST to SHOULD allows the WG some room to evaluate and potentially > select a candidate PA protocol that offers a subset or no PA security > while continuing to emphasize the WG preference for PA security > protections. Such flexibility should be beneficial during the WG > evaluations of candidate PA protocols. This would enable us to better > understand the impact on the PA protocol by including security > protections and allow for alternative countermeasures to be considered > (e.g. protection offered inside particular attributes). > > In order for the design team to stay on schedule, we ask that the WG > raise any objections to this approach ASAP so we can close discussions > by 5PM PDT on Tues, Oct 30th and prepare the draft for submission the > following day. > > Thanks, > > Paul _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea