From nea-bounces@ietf.org Mon Jan 16 04:04:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyQHg-0003bI-ON; Mon, 16 Jan 2006 04:04:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyQHe-0003aR-Uz for nea@megatron.ietf.org; Mon, 16 Jan 2006 04:04:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25557 for ; Mon, 16 Jan 2006 04:02:51 -0500 (EST) Received: from fmr20.intel.com ([134.134.136.19] helo=orsfmr005.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyQPX-0000WG-SP for nea@ietf.org; Mon, 16 Jan 2006 04:12:24 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k0G93wxD018607; Mon, 16 Jan 2006 09:03:58 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k0G93sAT026525; Mon, 16 Jan 2006 09:03:58 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006011601035703837 ; Mon, 16 Jan 2006 01:03:57 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 01:03:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] NEA "problem statement" I-D submitted Date: Mon, 16 Jan 2006 01:03:56 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E08134F3A@orsmsx408> Thread-Topic: [Nea] NEA "problem statement" I-D submitted Thread-Index: AcYGQoqpK94LQA7iRKSKn2ngXGQZ9AT5w7Ug From: "Khosravi, Hormuzd M" To: "Susan Thomson \(sethomso\)" , X-OriginalArrivalTime: 16 Jan 2006 09:03:57.0722 (UTC) FILETIME=[C8B4A7A0:01C61A7B] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2f0065339d489fe5a2873ea9ad776d1a Cc: Steve Hanna , Thomas Hardjono 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="===============0730741743==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0730741743== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61A7B.C8612EA0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61A7B.C8612EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Susan, All =20 Here is my feedback on the problem statement draft that you guys submitted... =20 Overall I think the draft is very well written, describes the problem, scope and terminology very well. Great job done by the authors! =20 Few comments... =20 The introduction states that NEA would 'optionally' influence network admission decision...why is this optional? =20 The use of the term "state" for describing posture in the Introduction section confuses me a bit...need to qualify this further since state means many things to many people =20 Figure 1 could be drawn in a better fashion showing multiple plugins interacting with the brokers, etc... to be more insync with what the text describes. I'll be happy to provide a more detailed picture if you like =20 I don't completely agree with 6.3.5 and 7. I feel like some of the interfaces such as the one between the server broker and server plugins should not be out of scope of this WG...this is an important interface for end-to-end interoperability and should be left within the scope of standardization =20 Need to add more references. Lots of references such as EAP, etc missing ---- =20 I feel like now is a good time to start discussion on BoF scope and goals. Let me know what you guys think, =20 Thanks Hormuzd ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Wednesday, December 21, 2005 7:24 AM To: nea@ietf.org Cc: Steve Hanna; Thomas Hardjono Subject: [Nea] NEA "problem statement" I-D submitted =20 Folks =20 This is a heads-up that a first draft of the co-authored "problem statement" I-D for "network endpoint assessment" has been sent to the secretariat for publication (draft-thomson-nea-problem-statement-00.txt). =20 The intent of the draft is to help us reach a common understanding of terms and model, and facilitate a discussion for identifying and prioritizing interfaces that may be candidates for standardization in the IETF. =20 Input from this discussion will be used to revise the document and scope a BOF on this topic currently targeted for the Spring meeting. =20 We would appreciate your feedback as soon as possible as BOF preparation timelines are fast approaching. (Please note I'll be out of the office and out of email contact from today till Jan 9, but Steve Hanna and Thomas Hardjono will be around. Steve is looking into posting the draft on a public site as well in the interim.). =20 Thanks Susan (and Steve and Thomas) =20 =20 ------_=_NextPart_001_01C61A7B.C8612EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Susan, All

 

Here is my feedback on the problem statement draft that you guys submitted…

 

Overall I think the draft is very = well written, describes the problem, scope and terminology very well. Great = job done by the authors!

 

Few = comments…

 

The introduction states that NEA = would ‘optionally’ influence network admission decision…why is this = optional?

 

The use of the term = “state” for describing posture in the Introduction section confuses me a = bit…need to qualify this further since state means many things to many = people

 

Figure 1 could be drawn in a better fashion showing multiple plugins interacting with the brokers, = etc… to be more insync with what the text describes. I’ll be happy to provide = a more detailed picture if you like

 

I don’t completely agree with = 6.3.5 and 7. I feel like some of the interfaces such as the one between the = server broker and server plugins should not be out of scope of this = WG…this is an important interface for end-to-end interoperability and should be = left within the scope of standardization

 

Need to add more references. Lots = of references such as EAP, etc missing

----

 

I feel like now is a good time to = start discussion on BoF scope and goals. Let me know what you guys = think,

 

Thanks

Hormuzd

From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso)
Sent: Wednesday, December = 21, 2005 7:24 AM
To: nea@ietf.org
Cc: Steve Hanna; Thomas = Hardjono
Subject: [Nea] NEA = "problem statement" I-D submitted

 

Folks

 

This is a heads-up that a first draft of the  co-authored "problem statement" I-D  for = "network endpoint assessment" has been sent to the secretariat for = publication (draft-thomson-nea-problem-statement-00.txt).

 

The intent of the draft is to help us reach = a common understanding of terms and model, and facilitate a discussion for identifying and prioritizing interfaces that may be candidates for standardization in the IETF.

 

Input from this discussion will be used to revise the document and scope a BOF on this topic currently targeted for the Spring meeting.

 

We would appreciate your feedback as soon as possible = as BOF preparation timelines are fast approaching. (Please note I'll be = out of the office and out of email contact from today till Jan 9, but Steve = Hanna and Thomas Hardjono will be around. Steve is looking into posting the draft = on a public site as well in the interim.).

 

Thanks

Susan (and Steve and Thomas)

 

 

------_=_NextPart_001_01C61A7B.C8612EA0-- --===============0730741743== 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 --===============0730741743==-- From nea-bounces@ietf.org Wed Jan 18 10:44:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFUJ-0000R4-BN; Wed, 18 Jan 2006 10:44:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFUG-0000Qm-LQ for nea@megatron.ietf.org; Wed, 18 Jan 2006 10:44:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27283 for ; Wed, 18 Jan 2006 10:43:13 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzFcZ-00077O-AK for nea@ietf.org; Wed, 18 Jan 2006 10:53:18 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2006 07:44:27 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0IFiMkB023610; Wed, 18 Jan 2006 07:44:26 -0800 (PST) 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.211); Wed, 18 Jan 2006 10:44:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] NEA "problem statement" I-D submitted Date: Wed, 18 Jan 2006 10:44:19 -0500 Message-ID: Thread-Topic: [Nea] NEA "problem statement" I-D submitted Thread-Index: AcYGQoqpK94LQA7iRKSKn2ngXGQZ9AT5w7UgAIR2/2A= From: "Susan Thomson \(sethomso\)" To: "Khosravi, Hormuzd M" , X-OriginalArrivalTime: 18 Jan 2006 15:44:21.0123 (UTC) FILETIME=[0C983D30:01C61C46] X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c4a3535d1556ada67f8703d3d31591 Cc: Steve Hanna , Thomas Hardjono 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="===============1890470076==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1890470076== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61C46.0C4AFE14" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61C46.0C4AFE14 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Hormuzd =20 Thanks for your review. =20 Responses inline ... ________________________________ From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]=20 Sent: Monday, January 16, 2006 4:04 AM To: Susan Thomson (sethomso); nea@ietf.org Cc: Steve Hanna; Thomas Hardjono Subject: RE: [Nea] NEA "problem statement" I-D submitted =09 =09 Hi Susan, All =20 Here is my feedback on the problem statement draft that you guys submitted... =20 Overall I think the draft is very well written, describes the problem, scope and terminology very well. Great job done by the authors! =20 Few comments... =20 The introduction states that NEA would 'optionally' influence network admission decision...why is this optional? [Susan] Its possible that users will deploy this technology in order to monitor compliance to security policy, rather than enforce it. This may happen on initial roll-out, in certain critical areas of the network, etc.=20 =20 The use of the term "state" for describing posture in the Introduction section confuses me a bit...need to qualify this further since state means many things to many people [Susan] Will try to clarify.=20 =20 Figure 1 could be drawn in a better fashion showing multiple plugins interacting with the brokers, etc... to be more insync with what the text describes. I'll be happy to provide a more detailed picture if you like [Susan] OK. I can send you source for this separately so that you can make proposed updates.=20 =20 I don't completely agree with 6.3.5 and 7. I feel like some of the interfaces such as the one between the server broker and server plugins should not be out of scope of this WG...this is an important interface for end-to-end interoperability and should be left within the scope of standardization [Susan] You refer to the interface between the "server broker and server plugin". Do you mean the interface between server broker and posture server, or something else? =20 I think there are two separate questions here: 1) whether these interfaces are candidates for standardization, and 2) whether the IETF is the place to do the standardization. For the purposes of this discussion, we are obviously interested in 2). To the extent these interfaces are APIs, this likely does not fall within the IETF. To the extent the interfaces are protocols (and this is the case where posture server is not co-located), then this is a candidate for standardization, although this may still be pushing the boundaries of what the IETF has traditionally been involved in. This is something that needs to be discussed further. =20 Need to add more references. Lots of references such as EAP, etc missing [Susan] Yes. The doc was sent out in somewhat incomplete form to get review as soon as possible. The intent is to update the document before the next IETF. ---- =20 I feel like now is a good time to start discussion on BoF scope and goals. Let me know what you guys think, [Susan] We need to start defining the BOF, since the cutoff date for a BOF request is 2/13, so will work on getting a draft proposal on the table. However, it is still important to get as much document feedback on the table asap, which will inform this charter. =20 Thanks=20 Susan =20 Thanks Hormuzd =09 ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Wednesday, December 21, 2005 7:24 AM To: nea@ietf.org Cc: Steve Hanna; Thomas Hardjono Subject: [Nea] NEA "problem statement" I-D submitted =20 Folks =20 This is a heads-up that a first draft of the co-authored "problem statement" I-D for "network endpoint assessment" has been sent to the secretariat for publication (draft-thomson-nea-problem-statement-00.txt). =20 The intent of the draft is to help us reach a common understanding of terms and model, and facilitate a discussion for identifying and prioritizing interfaces that may be candidates for standardization in the IETF. =20 Input from this discussion will be used to revise the document and scope a BOF on this topic currently targeted for the Spring meeting. =20 We would appreciate your feedback as soon as possible as BOF preparation timelines are fast approaching. (Please note I'll be out of the office and out of email contact from today till Jan 9, but Steve Hanna and Thomas Hardjono will be around. Steve is looking into posting the draft on a public site as well in the interim.). =20 Thanks Susan (and Steve and Thomas) =20 =20 ------_=_NextPart_001_01C61C46.0C4AFE14 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Hormuzd
 
Thanks for your review.
 
Responses inline ...

From: Khosravi, Hormuzd M=20 [mailto:hormuzd.m.khosravi@intel.com]
Sent: Monday, January = 16,=20 2006 4:04 AM
To: Susan Thomson (sethomso);=20 nea@ietf.org
Cc: Steve Hanna; Thomas = Hardjono
Subject: RE:=20 [Nea] NEA "problem statement" I-D submitted

Hi Susan,=20 All

 

Here is my = feedback=20 on the problem statement draft that you guys = submitted…

 

Overall I = think the=20 draft is very well written, describes the problem, scope and = terminology very=20 well. Great job done by the authors!

 

Few=20 comments…

 

The = introduction=20 states that NEA would ‘optionally’ influence network = admission decision…why is=20 this optional?
[Susan] Its possible that users will deploy this = technology=20 in order to monitor compliance to security policy, rather than = enforce=20 it. This may happen on initial roll-out, in certain critical = areas of the=20 network, etc. 

 

The use of = the term=20 “state” for describing posture in the Introduction section = confuses me a=20 bit…need to qualify this further since state means many things = to many=20 people
[Susan] Will try to=20 clarify. 

 

Figure 1 = could be=20 drawn in a better fashion showing multiple plugins interacting with = the=20 brokers, etc… to be more insync with what the text describes. = I’ll be happy to=20 provide a more detailed picture if you like
[Susan] OK. I = can send you=20 source for this separately so that you can make proposed=20 updates. 

 

I = don’t completely=20 agree with 6.3.5 and 7. I feel like some of the interfaces such as the = one=20 between the server broker and server plugins should not be out of = scope of=20 this WG…this is an important interface for end-to-end = interoperability and=20 should be left within the scope of standardization
[Susan] You refer to the = interface=20 between the "server broker and server plugin". Do you mean the = interface=20 between server broker and posture server, or something=20 else?

 

I think there are two = separate questions here: 1) whether these interfaces are = candidates=20 for standardization, and 2) whether the IETF is the place to = do the=20 standardization. For the purposes of this discussion, we are obviously = interested in 2).  To the extent these interfaces are APIs, this = likely=20 does not fall within the IETF. To the extent the interfaces are = protocols (and=20 this is the case where posture server is not co-located), then this = is a=20 candidate for standardization, although this may still be pushing = the=20 boundaries of what the IETF has traditionally been involved in. This = is=20 something that needs to be discussed = further.

 

 Need to=20 add more references. Lots of references such as =20 EAP, etc=20 missing
[Susan] Yes. The doc was sent out in=20 somewhat incomplete form to get review as soon as possible. = The=20 intent is to update the document  before the next=20 IETF.

----

 

I feel like = now is a=20 good time to start discussion on BoF scope and goals. Let me know what = you=20 guys think,
[Susan] We need to start defining the BOF, since = the cutoff=20 date for a BOF request is 2/13, so will work on getting a = draft=20 proposal on the table. However, it is still important to get as much = document=20 feedback on the table asap, which will inform this=20 charter.

 

Thanks=20

Susan

 

Thanks

Hormuzd

From:=20 nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson=20 (sethomso)
Sent: = Wednesday,=20 December 21, 2005 7:24 AM
To:=20 nea@ietf.org
Cc: = Steve Hanna;=20 Thomas Hardjono
Subject:=20 [Nea] NEA "problem statement" I-D submitted

 

Folks

 

This is a heads-up that = a first=20 draft of the  co-authored "problem statement" I-D  for = "network=20 endpoint assessment" has been sent to the secretariat for = publication=20 (draft-thomson-nea-problem-statement-00.txt).

 

The intent of the draft = is to=20 help us reach a common understanding of terms and model, and = facilitate a=20 discussion for identifying and prioritizing interfaces = that may=20 be candidates for standardization in the = IETF.

 

Input from this = discussion will be=20 used to revise the document and scope a BOF on this topic currently = targeted=20 for the Spring meeting.

 

We would appreciate your = feedback=20 as soon as possible as BOF preparation timelines are fast approaching. = (Please=20 note I'll be out of the office and out of email contact from = today till=20 Jan 9, but Steve Hanna and Thomas Hardjono will be around. Steve is = looking=20 into posting the draft on a public site as well in the=20 interim.).

 

Thanks

Susan (and Steve and=20 Thomas)

 

 

------_=_NextPart_001_01C61C46.0C4AFE14-- --===============1890470076== 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 --===============1890470076==-- From nea-bounces@ietf.org Thu Jan 19 20:29:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezl61-00008P-RY; Thu, 19 Jan 2006 20:29:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezl5v-00008C-9E for nea@megatron.ietf.org; Thu, 19 Jan 2006 20:29:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19184 for ; Thu, 19 Jan 2006 20:28:12 -0500 (EST) Received: from fmr20.intel.com ([134.134.136.19] helo=orsfmr005.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzlEW-0006Ci-GF for nea@ietf.org; Thu, 19 Jan 2006 20:38:35 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k0K1TK7K011915; Fri, 20 Jan 2006 01:29:20 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k0K1T3c4009973; Fri, 20 Jan 2006 01:29:20 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006011917291902595 ; Thu, 19 Jan 2006 17:29:19 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 17:29:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] NEA "problem statement" I-D submitted Date: Thu, 19 Jan 2006 17:29:19 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E08260E91@orsmsx408> Thread-Topic: [Nea] NEA "problem statement" I-D submitted Thread-Index: AcYGQoqpK94LQA7iRKSKn2ngXGQZ9AT5w7UgAIR2/2AARHPK4A== From: "Khosravi, Hormuzd M" To: "Susan Thomson \(sethomso\)" , X-OriginalArrivalTime: 20 Jan 2006 01:29:20.0284 (UTC) FILETIME=[EFBCEDC0:01C61D60] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 X-Spam-Score: 0.4 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: Steve Hanna , Thomas Hardjono 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="===============1136701365==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1136701365== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61D60.EF4E252B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61D60.EF4E252B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Susan =20 Yes I mean server broker & posture server. I agree that APIs don't fall within IETF standardization scope, however in this particular scenario, these entities are usually not co-located and protocols are used here. Therefore, I feel this should be something that is pursued by this working group, if we want to build interoperable solutions. =20 Thanks Hormuzd ________________________________ From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 I don't completely agree with 6.3.5 and 7. I feel like some of the interfaces such as the one between the server broker and server plugins should not be out of scope of this WG...this is an important interface for end-to-end interoperability and should be left within the scope of standardization [Susan] You refer to the interface between the "server broker and server plugin". Do you mean the interface between server broker and posture server, or something else? =20 I think there are two separate questions here: 1) whether these interfaces are candidates for standardization, and 2) whether the IETF is the place to do the standardization. For the purposes of this discussion, we are obviously interested in 2). To the extent these interfaces are APIs, this likely does not fall within the IETF. To the extent the interfaces are protocols (and this is the case where posture server is not co-located), then this is a candidate for standardization, although this may still be pushing the boundaries of what the IETF has traditionally been involved in. This is something that needs to be discussed further. =20 =20 Thanks=20 Susan ------_=_NextPart_001_01C61D60.EF4E252B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Susan
 
Yes I mean server broker & posture = server. I agree=20 that APIs don't fall within IETF standardization scope, however in this=20 particular scenario, these entities are usually not co-located and = protocols are=20 used here. Therefore, I feel this should be something that is pursued by = this=20 working group, if we want to build interoperable = solutions.
 
Thanks
Hormuzd

From: Susan Thomson (sethomso)=20 [mailto:sethomso@cisco.com]

I = don’t completely=20 agree with 6.3.5 and 7. I feel like some of the interfaces such as the = one=20 between the server broker and server plugins should not be out of = scope of=20 this WG…this is an important interface for end-to-end = interoperability and=20 should be left within the scope of standardization
[Susan] You refer to the = interface=20 between the "server broker and server plugin". Do you mean the = interface=20 between server broker and posture server, or something=20 else?

 

I think there are two = separate questions here: 1) whether these interfaces are = candidates=20 for standardization, and 2) whether the IETF is the place to = do the=20 standardization. For the purposes of this discussion, we are obviously = interested in 2).  To the extent these interfaces are APIs, this = likely=20 does not fall within the IETF. To the extent the interfaces are = protocols (and=20 this is the case where posture server is not co-located), then this = is a=20 candidate for standardization, although this may still be pushing = the=20 boundaries of what the IETF has traditionally been involved in. This = is=20 something that needs to be discussed = further.

 

 

Thanks=20

Susan

<= /BODY> ------_=_NextPart_001_01C61D60.EF4E252B-- --===============1136701365== 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 --===============1136701365==-- From nea-bounces@ietf.org Fri Jan 20 08:40:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzwUp-000643-VV; Fri, 20 Jan 2006 08:40:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzwUo-00063y-EJ for nea@megatron.ietf.org; Fri, 20 Jan 2006 08:40:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13155 for ; Fri, 20 Jan 2006 08:38:37 -0500 (EST) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzwdV-0004YY-6s for nea@ietf.org; Fri, 20 Jan 2006 08:49:06 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k0KDdlvp021284; Fri, 20 Jan 2006 13:39:47 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k0KDdj2l002491; Fri, 20 Jan 2006 13:39:47 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006012005394625659 ; Fri, 20 Jan 2006 05:39:46 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 05:39:46 -0800 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 05:39:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] NEA "problem statement" I-D submitted Date: Fri, 20 Jan 2006 08:37:33 -0500 Message-ID: <5404AEB459F8354F81995E038F343200024AC2E1@hdsmsx401.amr.corp.intel.com> Thread-Topic: [Nea] NEA "problem statement" I-D submitted Thread-Index: AcYGQoqpK94LQA7iRKSKn2ngXGQZ9AT5w7UgAIR2/2AARHPK4AAeTVow From: "Blumenthal, Uri" To: "Khosravi, Hormuzd M" , "Susan Thomson \(sethomso\)" , X-OriginalArrivalTime: 20 Jan 2006 13:39:46.0308 (UTC) FILETIME=[FA157C40:01C61DC6] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.20 X-Spam-Score: 0.7 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: Steve Hanna , Thomas Hardjono 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="===============0027081321==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0027081321== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61DC6.F8CB04E3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61DC6.F8CB04E3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I want to correct one statement here. API in general don't fall within IETF scope - HOWEVER there are some notable exceptions. Best-known example is GSS-API. =20 I second the opinion that interfaces are candidates as well, not just the protocols. ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Khosravi, Hormuzd M Sent: Friday, January 20, 2006 3:29 AM To: Susan Thomson (sethomso); nea@ietf.org Cc: Steve Hanna; Thomas Hardjono Subject: RE: [Nea] NEA "problem statement" I-D submitted =09 =09 Hi Susan =20 Yes I mean server broker & posture server. I agree that APIs don't fall within IETF standardization scope, however in this particular scenario, these entities are usually not co-located and protocols are used here. Therefore, I feel this should be something that is pursued by this working group, if we want to build interoperable solutions. =20 Thanks Hormuzd ________________________________ From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 I don't completely agree with 6.3.5 and 7. I feel like some of the interfaces such as the one between the server broker and server plugins should not be out of scope of this WG...this is an important interface for end-to-end interoperability and should be left within the scope of standardization [Susan] You refer to the interface between the "server broker and server plugin". Do you mean the interface between server broker and posture server, or something else? =20 I think there are two separate questions here: 1) whether these interfaces are candidates for standardization, and 2) whether the IETF is the place to do the standardization. For the purposes of this discussion, we are obviously interested in 2). To the extent these interfaces are APIs, this likely does not fall within the IETF. To the extent the interfaces are protocols (and this is the case where posture server is not co-located), then this is a candidate for standardization, although this may still be pushing the boundaries of what the IETF has traditionally been involved in. This is something that needs to be discussed further. =20 =20 Thanks=20 Susan ------_=_NextPart_001_01C61DC6.F8CB04E3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I want=20 to correct one statement here. API in general don't fall within = IETF=20 scope - HOWEVER there are some notable exceptions. Best-known = example is=20 GSS-API.
 
I=20 second the opinion that interfaces are candidates as well, not just the=20 protocols.

From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Khosravi, Hormuzd=20 M
Sent: Friday, January 20, 2006 3:29 AM
To: Susan = Thomson=20 (sethomso); nea@ietf.org
Cc: Steve Hanna; Thomas=20 Hardjono
Subject: RE: [Nea] NEA "problem statement" I-D=20 submitted

Hi Susan
 
Yes I mean server broker & posture = server. I=20 agree that APIs don't fall within IETF standardization scope, however = in this=20 particular scenario, these entities are usually not co-located and = protocols=20 are used here. Therefore, I feel this should be something that is = pursued by=20 this working group, if we want to build interoperable=20 solutions.
 
Thanks
Hormuzd

From: Susan Thomson (sethomso)=20 [mailto:sethomso@cisco.com]

I = don’t completely=20 agree with 6.3.5 and 7. I feel like some of the interfaces such as = the one=20 between the server broker and server plugins should not be out of = scope of=20 this WG…this is an important interface for end-to-end = interoperability and=20 should be left within the scope of standardization
[Susan] You refer to the = interface=20 between the "server broker and server plugin". Do you mean the = interface=20 between server broker and posture server, or something=20 else?

 

I think there are = two=20 separate questions here: 1) whether these interfaces are=20 candidates for standardization, and 2) whether the IETF=20 is the place to do the standardization. For the purposes = of this=20 discussion, we are obviously interested in 2).  To the extent = these=20 interfaces are APIs, this likely does not fall within the IETF. To = the=20 extent the interfaces are protocols (and this is the case where = posture=20 server is not co-located), then this is a candidate for=20 standardization, although this may still be pushing the = boundaries of=20 what the IETF has traditionally been involved in. This is something = that=20 needs to be discussed further.

 

 

Thanks=20

Susan

<= /BLOCKQUOTE> ------_=_NextPart_001_01C61DC6.F8CB04E3-- --===============0027081321== 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 --===============0027081321==-- From nea-bounces@ietf.org Mon Jan 23 16:53:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F19dE-0006jm-EJ; Mon, 23 Jan 2006 16:53:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F19dC-0006jX-ER for nea@megatron.ietf.org; Mon, 23 Jan 2006 16:53:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24173 for ; Mon, 23 Jan 2006 16:52:17 -0500 (EST) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F19mb-0007H3-Bb for nea@ietf.org; Mon, 23 Jan 2006 17:03:31 -0500 Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net [16.92.1.76]) by palrel12.hp.com (Postfix) with ESMTP id 52F7237E12; Mon, 23 Jan 2006 13:54:20 -0800 (PST) Received: from cacexc08.americas.cpqcorp.net ([16.92.1.35]) by cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 13:53:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jan 2006 13:53:26 -0800 Message-ID: Thread-Topic: Comments on NEA Problem statement Thread-Index: AcYgZ3BlLk89gH6fQO6Dt9OcLq8a3g== From: "Sanchez, Mauricio (PNB Roseville)" To: X-OriginalArrivalTime: 23 Jan 2006 21:53:27.0717 (UTC) FILETIME=[710F0D50:01C62067] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable Cc: Steve Hanna , THardjono@SignaCert.com Subject: [Nea] Comments on NEA Problem statement 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: , Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Finally had some time to look through the problem statement. It's a good start. Look forwarding to working with the team to get this one going... Substantive comment #1:=20 ------------------------ We may want to reconsider the problem statement of NEA [section 3]. While I do agree there's a general endpoint integrity/posture problem and solution, I don't agree that it is NEA's goal to solve this. I see the problem that NEA is trying to solve as one of interoperability, not of functionality. Customer's already have a functional solution for the endpoint integrity/posture problem. There is actually more than one solution - I can think of three: Trusted Computing Group's Trusted Network Connect, Cisco's Network Admission Control, and Microsoft's Network Access Protection. The problem with these solutions is that they are not at all interoperable. This is where I see NEA providing value by making some strides towards interoperability. We have to be careful on pinning down the scope of NEA. The document tends to mix together the desire to make existing architectures more interoperable through common protocols, but also takes the stance that NEA *will* support a number of diverse goals [section 4] that may or may not already be supported in existing architectures (i.e.). My opinion is the NEA should focus on assisting interoperability of what has already been defined in existing architectures and leave the rest for a different effort (or at least as a future goal and not an immediate one).=20 Moreover, the document spends a substantial amount of time creating new nomenclature and describing a new generalized architecture, even though it states up front [section 1] that it is not the intention of NEA to create a new framework. It seems that sections 2 through 6 have just done that and do not reference in any implicit or explicit manner existing architectures/efforts. My suggestion on these sections would be that they be more inclusive of existing architectures and discuss from the perspective that we have existing solutions to the endpoint integrity/posture problem, but they are currently incompatible and non-interoperable due to differing use of protocols and protocol bindings.=20 What I see to be the real aim of NEA only shows up until section 7 (scope of standardization). This section is good and could be improved by describing how existing architectures would benefit from having these interfaces standardized. =20 Speaking of interfaces... It is probably a misnomer to call NEA a standardization of various interfaces. I see the work being more one of standardization of protocol and/or protocol bindings. The term interface may be construed as meaning API's , which should not be the intention.=20 Substantive comment #2:=20 ----------------------- Role of trusted computing technology is not highlighted in any form. Although it shouldn't be mentioned as a normative reference, it should be brought in a way that has it as an informative reference. NITS of current draft --------------------- -Some of terminology not intuitive.=20 * NEA describes in its most basic form a client-server architecture. The NEA server is called out appropriately as a server. Why not do the same for the NEA agent by calling it the NEA client, instead? * It didn't strike me that 'NEA agent plug-ins' and 'NEA posture servers' are peers. =20 * Perhaps following nomencalture changes?=20 =09 Old New NEA agent NEA client NEA agent broker NEA client broker NEA agent plug-in NEA posture collector NEA posture server NEA posture validator All other remain same=20 -The fact that there may be multiple NEA plug-ins should be called out uniformly across the document. Section 2 does state that there may be multiple plug-ins, but Figure 1 and other sections of the document are not clear on this fact.=20 -Can there be multiple NEA agent brokers, access requestors, access authorities, or server brokers? -802.1X is spelled with a capital 'X'. =20 Section 1 -Fourth paragraph: Document never mentions by name the several existing architectures in existence. I can think of three - TCG's Trusted Network Connect (TNC), Cisco's Network Admissions Control (NAC), and Microsoft's Network Access Protection (NAP). Document should go on describe each architecture's relationship to generalized NEA architecture.=20 Figure 1 -Figure should show a plurality of NEA plug-ins and posture servers.=20 -'NEA Plug-in' label should be 'NEA Agent Plug-in' for correctness.=20 Section 2 Some definitions unclear. Details below: * NEA server : Is it just processing the posture information collected by the NEA agent? If so, the definition should call this out since it's not clear what "...assesses the posture of endpoint" actually entails.=20 * Network enforcer: Probably would be better to say that the network enforcer "enforces" the authorization decision than "implement" * Network access authority: Missing period at end of definition.=20 Section 5 This section should be written from the perspective of what current architectures support. Have to find the common use cases, which then serve to guide what the scope of NEA should be.=20 Section 5.1 Paragraph 2: Section 4 does not call out that NEA will explicitly support single or multiple hosts per switch. Again, considering whether support for this goal should be included should be predicated on what existing architectures support.=20 Section 5.4 Third paragraph: It is unclear whether NEA intends to support multiple network enforcers along a given network path. This paragraph points out the possibility, but doesn't state whether this is a supported use case. If it is a supported use case, it should be highlighted in section 4. Again, considering whether support for this goal should be included should be predicated on what existing architectures support.=20 Section 6.1 This section needs additional elaboration. Just how does NEA relate to EAP and AAA architectures? References would be nice. Section 6.2 Seems to duplicate a lot of the terminology already defined in section 2. =20 Section 6.2.2 Possibly think of changing 'implements' to 'enforces' Section 6.2.3 "...(which may or may not be co-located on a single server)." Why is this fact important to mention here? If they are not, then it raises the question of whether additional protocol needs are raised. Again, perhaps tying back to existing architectures would drive whether this statement needs to be made. Section 6.2.3.1 a. Missing period at end of paragraph. b. Who is makes the posture assessment? Where does the assessment decision come from? (I assume it's the NEA server broker and if so, probably should be explicitly stated).=20 Section 6.2.3.2 What happens to the server broker's assessment result? Section 6.3.5. This seems like a catch-all section. Consider removing. It doesn't add clarity to the problem statement nor work scope to say that there may be "other" interfaces without a clear reason why they need to be mentioned in the first place. Again, perhaps tying back to existing architectures and showing some examples of "other" interfaces would drive whether this statement needs to be made.=20 Section 6.4 What are your thoughts on what will go into this section? Section 7 -IMHO, this section would be much better if we described the protocol usage for each of the (three) existing architectures. This would give insight into just how big or small the job at hand is for NEA.=20 -On IF-PA, last sentence: Are there any examples of common attributes that would benefit from standardization? -On IF-PB: Doesn't EAPoUDP draft specify an EAP transport for L3 gateways already? -Would seem to me that there is some work, perhaps not finished.=20 -Can you provide a reference to the PANA WG work item mentioned?=20 -What non-standardized protocols have been designed? References? -Last paragraph: What remaining interfaces were identified? I only see four and all four are accounted four. Cheers, MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect Procurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5555 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- =20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jan 25 10:50:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1mvD-000114-Mj; Wed, 25 Jan 2006 10:50:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1mvB-00010Z-Ko for nea@megatron.ietf.org; Wed, 25 Jan 2006 10:50:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22280 for ; Wed, 25 Jan 2006 10:49:25 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1n4v-0005cR-8T for nea@ietf.org; Wed, 25 Jan 2006 11:01:04 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 25 Jan 2006 07:50:43 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0PFogKT021528 for ; Wed, 25 Jan 2006 07:50:43 -0800 (PST) Received: from xmb-rtp-209.amer.cisco.com ([64.102.31.11]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 10:50:42 -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: Wed, 25 Jan 2006 10:50:41 -0500 Message-ID: <711A1D9897F2F04B9C166616EC8ED93E011AD324@xmb-rtp-209.amer.cisco.com> Thread-Topic: Comments on NEA Problem Statement Thread-Index: AcYhCI6+Tanv3wxWTW+yeNFSdBhy1gAvUUgg From: "Brian Ford \(brford\)" To: X-OriginalArrivalTime: 25 Jan 2006 15:50:42.0762 (UTC) FILETIME=[18F5FAA0:01C621C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Subject: [Nea] RE: Comments on NEA Problem Statement 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: , Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org =20 Mauricio, Great message. I disagree with your assessment that there are only three solutions that need to be considered. There are several very large and established security vendors not represented there as well as a number of start ups. Some of these others are bringing interesting alternatives to the table in their solutions. I don't believe section 1 of the problem statement defined an architecture as much as it tried to put some bounds around what is out there right now. Given that this IETF effort is still in the early formative stages don't you think we should refine the bounds and scope of the problem space before we start to consider interoperability? Liberty for All, Brian=20 -----Original Message----- Date: Mon, 23 Jan 2006 13:53:26 -0800 From: "Sanchez, Mauricio (PNB Roseville)" Subject: [Nea] Comments on NEA Problem statement To: Cc: Steve Hanna , THardjono@SignaCert.com Finally had some time to look through the problem statement. It's a good start. Look forwarding to working with the team to get this one going... Substantive comment #1:=20 ------------------------ We may want to reconsider the problem statement of NEA [section 3]. While I do agree there's a general endpoint integrity/posture problem and solution, I don't agree that it is NEA's goal to solve this. I see the problem that NEA is trying to solve as one of interoperability, not of functionality. Customer's already have a functional solution for the endpoint integrity/posture problem. There is actually more than one solution - I can think of three: Trusted Computing Group's Trusted Network Connect, Cisco's Network Admission Control, and Microsoft's Network Access Protection. The problem with these solutions is that they are not at all interoperable. This is where I see NEA providing value by making some strides towards interoperability. We have to be careful on pinning down the scope of NEA. The document tends to mix together the desire to make existing architectures more interoperable through common protocols, but also takes the stance that NEA *will* support a number of diverse goals [section 4] that may or may not already be supported in existing architectures (i.e.). My opinion is the NEA should focus on assisting interoperability of what has already been defined in existing architectures and leave the rest for a different effort (or at least as a future goal and not an immediate one).=20 Moreover, the document spends a substantial amount of time creating new nomenclature and describing a new generalized architecture, even though it states up front [section 1] that it is not the intention of NEA to create a new framework. It seems that sections 2 through 6 have just done that and do not reference in any implicit or explicit manner existing architectures/efforts. My suggestion on these sections would be that they be more inclusive of existing architectures and discuss from the perspective that we have existing solutions to the endpoint integrity/posture problem, but they are currently incompatible and non-interoperable due to differing use of protocols and protocol bindings.=20 What I see to be the real aim of NEA only shows up until section 7 (scope of standardization). This section is good and could be improved by describing how existing architectures would benefit from having these interfaces standardized. =20 Speaking of interfaces... It is probably a misnomer to call NEA a standardization of various interfaces. I see the work being more one of standardization of protocol and/or protocol bindings. The term interface may be construed as meaning API's , which should not be the intention.=20 Substantive comment #2:=20 ----------------------- Role of trusted computing technology is not highlighted in any form. Although it shouldn't be mentioned as a normative reference, it should be brought in a way that has it as an informative reference. Cheers, MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect Procurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5555 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- =20 ------------------------------ _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea End of Nea Digest, Vol 3, Issue 4 ********************************* _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jan 25 17:17:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1sws-000780-Pc; Wed, 25 Jan 2006 17:17:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1slE-0001w1-F6 for nea@megatron.ietf.org; Wed, 25 Jan 2006 17:05:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27240 for ; Wed, 25 Jan 2006 17:03:32 -0500 (EST) Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1sv2-0003XA-0S for nea@ietf.org; Wed, 25 Jan 2006 17:15:14 -0500 Received: from snicker.merit.edu (snicker.merit.edu [198.108.62.156]) by segue.merit.edu (Postfix) with ESMTP id A740C58281; Wed, 25 Jan 2006 17:04:53 -0500 (EST) Received: from [198.108.62.85] (dhcp62-85.merit.edu [198.108.62.85]) by snicker.merit.edu (Postfix) with ESMTP id 6871B171884; Wed, 25 Jan 2006 17:04:53 -0500 (EST) In-Reply-To: <711A1D9897F2F04B9C166616EC8ED93E011AD324@xmb-rtp-209.amer.cisco.com> References: <711A1D9897F2F04B9C166616EC8ED93E011AD324@xmb-rtp-209.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Vollbrecht Subject: Re: [Nea] RE: Comments on NEA Problem Statement Date: Wed, 25 Jan 2006 17:04:55 -0500 To: "Brian Ford ((brford))" , NEA X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 Jan 2006 17:17:05 -0500 Cc: John Vollbrecht 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: , Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Brian and Mauricio - Good dialog - A few comments below - On Jan 25, 2006, at 10:50 AM, Brian Ford ((brford)) wrote: > > Mauricio, > > Great message. > > I disagree with your assessment that there are only three solutions > that > need to be considered. There are several very large and established > security vendors not represented there as well as a number of start > ups. > Some of these others are bringing interesting alternatives to the > table > in their solutions. > I think it would be good if others brought their solutions to the table. Certainly IETF will provide an environment where all may be brought to the table and be considered. It is my guess, however, that all higher layer solutions have a significant amount in common in their architecture, and have common lower layer needs. Again, in my opinion, it is these lower layer needs that make this interesting for IETF. The architecture of each solution has needs for lower layer(s) that are appropriate for IETF to define. Given this, I agree with Mauricio that the first sections seem to attempt to define (new) terminology and architecture and imply that this is the area where standardization is expected. In my opinion, the new terminology does seem to be needed, but to provide a tool to show existing solutions compare and to use these real world/existing solutions to define a strong set of uses cases and requirements for standardizing lower layers. If this is what is intended, then I suggest a statement that this is what is intended, and inviting others to share their architectures for the sake of creating use cases for defining requirements for standardization of the lower layer. > I don't believe section 1 of the problem statement defined an > architecture as much as it tried to put some bounds around what is out > there right now. > I guess one could see this either way. My first take was this was an attempt to create a architecture based on existing implementations. My question is whether implementors of existing solutions see these as useful in describing their implementation. > Given that this IETF effort is still in the early formative stages > don't > you think we should refine the bounds and scope of the problem space > before we start to consider interoperability? > I agree that we should have dialog about bounds and scope. My comments are meant to be input to such a discussion. I also think that the areas of interoperability that are included and how they are prioritized in terms of work items is important. In my opinion the transport layer is the place where IETF standards are needed by all the existing implementations (I may be wrong) and that this is the highest priority area. > Liberty for All, > > Brian > John > > -----Original Message----- > > Date: Mon, 23 Jan 2006 13:53:26 -0800 > From: "Sanchez, Mauricio (PNB Roseville)" > Subject: [Nea] Comments on NEA Problem statement > To: > Cc: Steve Hanna , THardjono@SignaCert.com > > Finally had some time to look through the problem statement. It's a > good start. Look forwarding to working with the team to get this one > going... > > > Substantive comment #1: > ------------------------ > > We may want to reconsider the problem statement of NEA [section 3]. > While I do agree there's a general endpoint integrity/posture problem > and solution, I don't agree that it is NEA's goal to solve this. I > see > the problem that NEA is trying to solve as one of interoperability, > not > of functionality. Customer's already have a functional solution > for the > endpoint integrity/posture problem. There is actually more than one > solution - I can think of three: Trusted Computing Group's Trusted > Network Connect, Cisco's Network Admission Control, and Microsoft's > Network Access Protection. The problem with these solutions is that > they are not at all interoperable. This is where I see NEA providing > value by making some strides towards interoperability. > > We have to be careful on pinning down the scope of NEA. The document > tends to mix together the desire to make existing architectures more > interoperable through common protocols, but also takes the stance that > NEA *will* support a number of diverse goals [section 4] that may > or may > not already be supported in existing architectures (i.e.). My opinion > is the NEA should focus on assisting interoperability of what has > already been defined in existing architectures and leave the rest > for a > different effort (or at least as a future goal and not an immediate > one). > > Moreover, the document spends a substantial amount of time creating > new > nomenclature and describing a new generalized architecture, even > though > it states up front [section 1] that it is not the intention of NEA to > create a new framework. It seems that sections 2 through 6 have just > done that and do not reference in any implicit or explicit manner > existing architectures/efforts. My suggestion on these sections would > be that they be more inclusive of existing architectures and discuss > from the perspective that we have existing solutions to the endpoint > integrity/posture problem, but they are currently incompatible and > non-interoperable due to differing use of protocols and protocol > bindings. > > What I see to be the real aim of NEA only shows up until section 7 > (scope of standardization). This section is good and could be > improved > by describing how existing architectures would benefit from having > these > interfaces standardized. > > Speaking of interfaces... It is probably a misnomer to call NEA a > standardization of various interfaces. I see the work being more > one of > standardization of protocol and/or protocol bindings. The term > interface > may be construed as meaning API's , which should not be the intention. > > Substantive comment #2: > ----------------------- > Role of trusted computing technology is not highlighted in any form. > Although it shouldn't be mentioned as a normative reference, it should > be brought in a way that has it as an informative reference. > > > > Cheers, > MS > > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > Procurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5555 > Roseville CA, 95747-5557 > > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- > > > > > ------------------------------ > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > > > End of Nea Digest, Vol 3, Issue 4 > ********************************* > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jan 25 18:06:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1tiE-0003qN-7x; Wed, 25 Jan 2006 18:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1tiC-0003qF-Cq for nea@megatron.ietf.org; Wed, 25 Jan 2006 18:06:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02262 for ; Wed, 25 Jan 2006 18:04:26 -0500 (EST) Received: from ogo.signacert.com ([207.162.214.7] helo=mail.signacert.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1try-0005ac-EX for nea@ietf.org; Wed, 25 Jan 2006 18:16:09 -0500 Received: from SCTHOMASTP42 (unknown [207.162.210.168]) by mail.signacert.com (Postfix) with ESMTP id 77E3A18EC456 for ; Wed, 25 Jan 2006 15:05:33 -0800 (PST) From: "Thomas Hardjono" To: Date: Wed, 25 Jan 2006 15:05:31 -0800 Organization: SignaCert Message-ID: <005101c62203$d7df9c00$9d03a8c0@SCTHOMASTP42> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYhCI6+Tanv3wxWTW+yeNFSdBhy1gAvUUggAA953rA= In-Reply-To: <711A1D9897F2F04B9C166616EC8ED93E011AD324@xmb-rtp-209.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Nea] IETF cutoff Dates X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: THardjono@SignaCert.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org FYI. Just in case you have not seen these. January 16, Monday - Working Group and BOF scheduling begins February 13, Monday - Cutoff date for requests to schedule Working Group and BOF meetings at 17:00 ET (22:00 GMT) February 17, Friday - Preliminary agenda published for comment February 20, Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 09:00 ET (14:00 GMT) February 22, Wednesday - Cutoff date for requests to reschedule Working Group and BOF meetings 09:00 ET (14:00 GMT) February 27, Monday - Final Working Group and BOF agenda to be published February 27, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 GMT) March 6, Monday - Internet Draft final submission cut-off by 09:00 ET (14:00 GMT) March 8, Wednesday - Pre-Registration and Pre-payment cut-off at 12:00 noon ET (17:00 GMT) March 13, Monday - Working Group agendas due date by 12:00 ET (17:00 GMT), upload using IETF Meeting Materials Management Tool March 13, Monday - Registration cancellation cut-off at 17:00 ET (22:00 GMT) March 19-24, 2006 - 65th IETF Meeting in Dallas, TX, USA ** Times are in US Eastern Time and GMT ** _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 26 11:34:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2A4j-0007RJ-RO; Thu, 26 Jan 2006 11:34:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2A4i-0007RE-1W for nea@megatron.ietf.org; Thu, 26 Jan 2006 11:34:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02288 for ; Thu, 26 Jan 2006 11:32:47 -0500 (EST) Received: from smtp.mail.umich.edu ([141.211.14.81] helo=hackers.mr.itd.umich.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2AEf-0003Ek-0D for nea@ietf.org; Thu, 26 Jan 2006 11:44:39 -0500 Received: FROM [207.75.165.246] (wlan246.internet2.edu [207.75.165.246]) BY hackers.mr.itd.umich.edu ID 43D8F9C5.7FCB1.11847 ; 26 Jan 2006 11:33:09 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Vollbrecht Subject: Re: [Nea] RE: Comments on NEA Problem Statement[repost] Date: Thu, 26 Jan 2006 11:33:11 -0500 To: NEA X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: 7bit Cc: John Vollbrecht 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: , Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Brian and Mauricio - Good dialog - A few comments below - On Jan 25, 2006, at 10:50 AM, Brian Ford ((brford)) wrote: > > Mauricio, > > Great message. > > I disagree with your assessment that there are only three solutions > that > need to be considered. There are several very large and established > security vendors not represented there as well as a number of start > ups. > Some of these others are bringing interesting alternatives to the > table > in their solutions. > > I think it would be good if others brought their solutions to the table. Certainly IETF will provide an environment where all may be brought to the table and be considered. It is my guess, however, that all higher layer solutions have a significant amount in common in their architecture, and have common lower layer needs. Again, in my opinion, it is these lower layer needs that make this interesting for IETF. The architecture of each solution has needs for lower layer(s) that are appropriate for IETF to define. Given this, I agree with Mauricio that the first sections seem to attempt to define (new) terminology and architecture and imply that this is the area where standardization is expected. In my opinion, the new terminology does seem to be needed, but to provide a tool to show existing solutions compare and to use these real world/existing solutions to define a strong set of uses cases and requirements for standardizing lower layers. If this is what is intended, then I suggest a statement that this is what is intended, and inviting others to share their architectures for the sake of creating use cases for defining requirements for standardization of the lower layer. > I don't believe section 1 of the problem statement defined an > architecture as much as it tried to put some bounds around what is out > there right now. > > I guess one could see this either way. My first take was this was an attempt to create a architecture based on existing implementations. My question is whether implementors of existing solutions see these as useful in describing their implementation. > Given that this IETF effort is still in the early formative stages > don't > you think we should refine the bounds and scope of the problem space > before we start to consider interoperability? > > I agree that we should have dialog about bounds and scope. My comments are meant to be input to such a discussion. I also think that the areas of interoperability that are included and how they are prioritized in terms of work items is important. In my opinion the transport layer is the place where IETF standards are needed by all the existing implementations (I may be wrong) and that this is the highest priority area. > Liberty for All, > > Brian > > John > > -----Original Message----- > > Date: Mon, 23 Jan 2006 13:53:26 -0800 > From: "Sanchez, Mauricio (PNB Roseville)" > Subject: [Nea] Comments on NEA Problem statement > To: > Cc: Steve Hanna , THardjono@SignaCert.com > > Finally had some time to look through the problem statement. It's a > good start. Look forwarding to working with the team to get this one > going... > > > Substantive comment #1: > ------------------------ > > We may want to reconsider the problem statement of NEA [section 3]. > While I do agree there's a general endpoint integrity/posture problem > and solution, I don't agree that it is NEA's goal to solve this. I > see > the problem that NEA is trying to solve as one of interoperability, > not > of functionality. Customer's already have a functional solution > for the > endpoint integrity/posture problem. There is actually more than one > solution - I can think of three: Trusted Computing Group's Trusted > Network Connect, Cisco's Network Admission Control, and Microsoft's > Network Access Protection. The problem with these solutions is that > they are not at all interoperable. This is where I see NEA providing > value by making some strides towards interoperability. > > We have to be careful on pinning down the scope of NEA. The document > tends to mix together the desire to make existing architectures more > interoperable through common protocols, but also takes the stance that > NEA *will* support a number of diverse goals [section 4] that may > or may > not already be supported in existing architectures (i.e.). My opinion > is the NEA should focus on assisting interoperability of what has > already been defined in existing architectures and leave the rest > for a > different effort (or at least as a future goal and not an immediate > one). > > Moreover, the document spends a substantial amount of time creating > new > nomenclature and describing a new generalized architecture, even > though > it states up front [section 1] that it is not the intention of NEA to > create a new framework. It seems that sections 2 through 6 have just > done that and do not reference in any implicit or explicit manner > existing architectures/efforts. My suggestion on these sections would > be that they be more inclusive of existing architectures and discuss > from the perspective that we have existing solutions to the endpoint > integrity/posture problem, but they are currently incompatible and > non-interoperable due to differing use of protocols and protocol > bindings. > > What I see to be the real aim of NEA only shows up until section 7 > (scope of standardization). This section is good and could be > improved > by describing how existing architectures would benefit from having > these > interfaces standardized. > > Speaking of interfaces... It is probably a misnomer to call NEA a > standardization of various interfaces. I see the work being more > one of > standardization of protocol and/or protocol bindings. The term > interface > may be construed as meaning API's , which should not be the intention. > > Substantive comment #2: > ----------------------- > Role of trusted computing technology is not highlighted in any form. > Although it shouldn't be mentioned as a normative reference, it should > be brought in a way that has it as an informative reference. > > > > Cheers, > MS > > -------------------------------------------- > Mauricio Sanchez, CISSP > Network Security Architect > Procurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5555 > Roseville CA, 95747-5557 > > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- > > > > > ------------------------------ > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > > > End of Nea Digest, Vol 3, Issue 4 > ********************************* > > _______________________________________________ > 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 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 26 13:03:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BTT-0002sU-5E; Thu, 26 Jan 2006 13:03:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BTQ-0002pY-Ch for nea@megatron.ietf.org; Thu, 26 Jan 2006 13:03:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10662 for ; Thu, 26 Jan 2006 13:02:22 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2BdO-000873-9L for nea@ietf.org; Thu, 26 Jan 2006 13:14:16 -0500 Received: by zproxy.gmail.com with SMTP id 9so431788nzo for ; Thu, 26 Jan 2006 10:03:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=gKMeDb8XjrnLloGg054DRYb3Vt6O5yPLMUBO/AtSJe5WNG2ZAzrE1zOQN+pgLcBKXnZAl0V8KPHAsv/2OHEKuVtckGgjFmkNURBkkICCGwQc8eMP3Sl+vYdXuRM4mG+PZWM7GUU44g//OpU439UIturfOQhbdTTEGB4o7zhdx/4= Received: by 10.36.39.4 with SMTP id m4mr1127212nzm; Thu, 26 Jan 2006 10:03:50 -0800 (PST) Received: by 10.36.46.13 with HTTP; Thu, 26 Jan 2006 10:03:50 -0800 (PST) Message-ID: Date: Thu, 26 Jan 2006 10:03:50 -0800 From: Sean Convery To: nea@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Subject: [Nea] Comments on draft-thomson-nea-problem-statement-00.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: , Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Hello all, I'm new to the list so apologies if my comments tread on well worn ground. Overall I found the document does a good job of describing the ultimate goal and then a brief framework for an architecture to address the goal. I think it may be useful to have something in between which discusses some of the challenges in realizing the goal which helped inform the choices in the summarized architecture. I also think more discussion around higher-layer approaches to NEA might be useful in the doc. These higher layer approaches may in the end use the same components defined in the current draft but they may be invoked and initially provisioned in different ways. This could possibly be addressed through an expansion of Section 5. Specific comments below and some nits. Thanks, Sean Section 2: Is "Network access requestor" the right term? Can't the protocol that makes the network access request be distinct from the one who responds if challenged by the network for posture information? Would "NEA network interface" or something similar be better? The existing naming implies a tighter linkage between NEA and existing network AAA systems that may be desired especially at the problem stage. Section 2: Similar to my comment on the "network access requestor" name, network access authority implies a similar linkage to existing AAA which we may not want at this stage of the work. I agree AAA is a natural home for NEA functions but there are others. Section 3, access technologies (should we include either Web authentication / captive portal or SSL based VPN?) Section 4 bullet 1: Should we mention heterogeneous vendor support of all the main components or is that assumed since this is the IETF? :) Section 4 bullet 2: Again introducing user and device seems odd but if we keep it in, it should be "or all three", not or both. Overall I think we need more words on the interactions of the existing AAA system with NEA if we want to be linked so closely in terms of capabilities. Section 4 bullet 3 - What about things operating above L3 to control network access such as captive portals? Section 4 last bullet - Is agent vs. no agent really binary? What about a downloadable applet at the time the user hits a captive portal? Couldn't there be a mix of the NEA subcomponents some of which are static on an endpoint and some of which are dynamically loaded to do the posture check? This may not materially affect the standards but some mention of it might be useful since this is a problem statement doc. In fact, I wonder if this whole document needs more discussion of the challenges to solving the NEA problem; discussions about resistance to run new client code, challenges in troubleshooting NEA deployments, etc.. This is the first IETF problem statement doc I've reviewed so pardon my ignorance if that sort of thing is not generally discussed. It seems that as the IETF evaluates potential solutions to the problem statement in this doc, some more words around what deployment challenges to keep in mind would be useful. This could be an expansion of section 4. 6.1 - if you put this section earlier in the doc and expanded it some of my earlier comments around the AAA discussion would be addressed. 6.2.1.1 Bullet 3 - Shouldn't this be instead indicating when the posture of a security element under the purview of that particular plug-in has changed? 9.3 - This seems like an important security consideration but not one which could be obviously addressed through the proposed scope of standardization. *Nits* Be consistent with capitalization of terms. Section 5.4 - Third paragraph seems like a viable use in its own right so perhaps it should precede the migration paragraph. Section 6 - Suggest rewording the first sentence as follows: Figure 1 shows the a high-level diagram of the overall NEA system and interfaces, each of which is elaborated in subsequent subsections. 6.1 Radius should be RADIUS. 6.2.1.1 - software that provide -> software that provides there may be many plug-ins in an agent, one per vendor and application type -> there may be many plug-ins in an agent (i.e. one per vendor or application type). Bullet 2 - information any actions --> information on any actions 9.2 - Server Broker should only communicate with authorized NEA --> Server Broker should only communicate with an authorized NEA _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jan 31 10:16:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xEx-0001Jl-24; Tue, 31 Jan 2006 10:16:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xEv-0001Gw-Ld for nea@megatron.ietf.org; Tue, 31 Jan 2006 10:16:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24698 for ; Tue, 31 Jan 2006 10:14:32 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3xPl-0006kt-E8 for nea@ietf.org; Tue, 31 Jan 2006 10:27:31 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 31 Jan 2006 07:15:58 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0VFFgWL011614; Tue, 31 Jan 2006 07:15:57 -0800 (PST) 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.211); Tue, 31 Jan 2006 10:15:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 31 Jan 2006 10:15:51 -0500 Message-ID: Thread-Topic: NEA BOF request: Cut-off date is THIS week Thread-Index: AcYmeTiyFgunobxzSWC3zR/OzP8YdQ== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 31 Jan 2006 15:15:52.0104 (UTC) FILETIME=[394F6280:01C62679] X-Spam-Score: 0.6 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: Steve Hanna Subject: [Nea] NEA BOF request: Cut-off date is THIS week 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="===============0956147971==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0956147971== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62679.38FE93C5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62679.38FE93C5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Folks In the next couple of messages, Steve and I will be sending a draft agenda and draft charter for a NEA BOF at Spring IETF for review. Please note that the ADs have placed an internal deadline for BOF requests in the Internet area which is this Friday Feb 3 (see message below). This is earlier than the official IETF deadline of Feb 13. Please review the agenda and charter and provide comments by no later than COB Thursday this week, so that we can incorporate comments by Friday. Note that feedback on the mailing list is used as an indicator that we have a critical mass of support for making this request so your input is very important. Even if you do not have specific comments at this time, a one-liner indicating your support (or not) would be helpful.=20 In the meantime, we would like to thank those who have commented on the problem statement I-D. There have been excellent points made. We will be responding to these comments and incorporating feedback into a revised I-D once the short fuse work re the BOF request has been completed. The final cut-off date for revised I-Ds is March 6. We need more feedback though, and look forward to hearing from more of you once you have commented on the agenda and charter. Thanks Susan & Steve -----Original Message----- From: Mark Townsley (townsley) Sent: Friday, January 27, 2006 1:04 PM To: Susan Thomson (sethomso); Joseph Salowey (jsalowey) Subject: [Fwd: BoF requests for Dallas] =20 =20 -------- Original Message -------- Subject: BoF requests for Dallas Date: Tue, 20 Dec 2005 05:08:04 +0100 From: Mark Townsley Reply-To: Mark Townsley , Margaret Wasserman=20 To: Internet Area , int-chairs@ietf.org =20 Apologies in advance for the cross-posting. We are getting a lot of BoF requests in the int-area. That's not a bad thing, but in order to better manage them we would like to enforce the following deadlines for the next IETF meeting: Jan 20 - Creation of a public mailing list for discussion of the BoF topic at hand. Please include Margaret and I on this list so that we can monitor the discussion. Feb 3 - Formal request to the ietf-secretary and ADs, cc'd to the public mailing list, for the BoF itself. Included in the request should be a draft BoF Agenda, if the goal is the formation of a WG a draft charter, and a pointer to at least one Internet Draft as reference material for the BoF itself. Also, please take a look at Thomas' document on how to run a successful BoF. This is a brand new document, and Thomas is asking for review and discussion (which you can do on the int-area, iab, iesg or ietf list as you like) and volunteers to help iterate on the text and ready it for publication. http://www.ietf.org/internet-drafts/draft-narten-successful-bof-00.txt Thanks! - Mark and Margaret PS. Should we make int-chairs a member of int-area and clean-up duplicates (making int-chairs a forced subset of int-area)? ------_=_NextPart_001_01C62679.38FE93C5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Folks

In the next couple of messages, Steve and = I will be=20 sending a draft agenda and draft charter for a NEA BOF  at Spring IETF for review.

Please note that the ADs have placed an = internal=20 deadline for BOF requests in the Internet area which is this = Friday Feb 3 (see message below). This is = earlier than=20 the official IETF deadline of Feb=20 13.

Please review the agenda and = charter and=20 provide comments by no later than = COB=20 Thursday this week, so = that we can=20 incorporate comments by Friday. Note that feedback on the mailing list = is used=20 as an indicator that we have a critical mass of support for making this request so your input is = very=20 important. Even if you do not have = specific=20 comments at this time, a one-liner indicating your support (or not) = would be=20 helpful.

In the meantime, we would like to thank = those who=20 have commented on the problem statement I-D. There have been excellent = points=20 made. We will be responding to these comments and incorporating feedback = into a=20 revised I-D once the short = fuse work re=20 the BOF request has been completed. The final cut-off date for revised I-Ds=20 is March 6. We need more = feedback=20 though, and look forward to hearing from more of you once you have = commented on=20 the agenda and charter.

Thanks

Susan & Steve

-----Original Message-----

From: Mark Townsley (townsley)

Sent: Friday, January 27, 2006 1:04 = PM

To: Susan Thomson (sethomso); Joseph = Salowey=20 (jsalowey)

Subject: [Fwd: BoF requests for = Dallas]

 

 

-------- Original Message = --------

Subject: BoF requests for = Dallas

Date: Tue, 20 Dec 2005 05:08:04 = +0100

From: Mark Townsley=20 <townsley@cisco.com>

Reply-To: Mark Townsley = <townsley@cisco.com>,=20 Margaret Wasserman

<margaret@thingmagic.com>

To: Internet Area = <int-area@ietf.org>,=20 int-chairs@ietf.org

 

Apologies in advance for the=20 cross-posting.

We are getting a lot of BoF requests in = the int-area.=20 That's not a bad thing, but in order to better manage them we would like = to=20 enforce the following deadlines for the next IETF meeting:

Jan 20 - Creation of a public mailing = list for=20 discussion of the BoF topic at hand. Please include Margaret and I on = this list=20 so that we can monitor the discussion.

Feb 3 - Formal request to the = ietf-secretary and ADs,=20 cc'd to the public mailing list, for the BoF itself. Included in the = request=20 should be a draft BoF Agenda, if the goal is the formation of a WG a = draft=20 charter, and a pointer to at least one Internet Draft as reference = material for=20 the BoF itself.

Also, please take a look at Thomas' = document on how=20 to run a successful BoF. This is a brand new document, and Thomas is = asking for=20 review and discussion (which you can do on the int-area, iab, iesg or = ietf list=20 as you

like) and volunteers to help iterate on = the text and=20 ready it for publication.

http://www.ietf.org/internet-drafts/draft-narten-successful-bof-= 00.txt

Thanks!

- Mark and Margaret

PS. Should we make int-chairs a member of = int-area=20 and clean-up duplicates (making int-chairs a forced subset of=20 int-area)?

------_=_NextPart_001_01C62679.38FE93C5-- --===============0956147971== 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 --===============0956147971==-- From nea-bounces@ietf.org Tue Jan 31 10:26:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xOg-0004JG-Kv; Tue, 31 Jan 2006 10:26:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xOf-0004IF-7z for nea@megatron.ietf.org; Tue, 31 Jan 2006 10:26:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26553 for ; Tue, 31 Jan 2006 10:24:44 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3xZd-0007PG-UL for nea@ietf.org; Tue, 31 Jan 2006 10:37:43 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 31 Jan 2006 10:26:12 -0500 X-IronPort-AV: i="4.01,239,1136178000"; d="scan'208,217"; a="81388822:sNHT48226468" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0VFPwPQ003925; Tue, 31 Jan 2006 10:26:08 -0500 (EST) 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.211); Tue, 31 Jan 2006 10:25:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 31 Jan 2006 10:25:58 -0500 Message-ID: Thread-Topic: Draft NEA BOF agenda: Please review Thread-Index: AcYmeqKqLnTdgJBzQqeBA8wrp30n+Q== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 31 Jan 2006 15:25:59.0193 (UTC) FILETIME=[A329D090:01C6267A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Steve Hanna Subject: [Nea] Draft NEA BOF agenda: Please review 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="===============0871919868==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0871919868== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6267A.A2E5A723" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6267A.A2E5A723 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Network Endpoint Assessment (NEA) BOF Draft Agenda =20 Agenda Bashing (5 minutes) NEA Problem Statement (45 minutes) Proposed NEA Charter (45 minutes) Consensus Check and Volunteering (25 minutes) =20 The goal of the NEA BOF is to confirm rough consensus on the NEA problem statement, on the importance of forming an IETF Working Group to address the problems described in that document, and on the proposed charter for such a Working Group. Further, the NEA BOF will verify that there are enough participants to make the NEA effort a success. =20 NEA BOF participants are expected to have read the documents listed below before the BOF meeting. Discussion of these documents before the BOF meeting is strongly encouraged. It will take place on the nea@ietf.org mailing lis =20 Proposed NEA Charter =20 Network Endpoint Assessment (NEA) Problem Statement ------_=_NextPart_001_01C6267A.A2E5A723 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Network Endpoint=20 Assessment (NEA) BOF Draft Agenda
 
Agenda = Bashing (5=20 minutes)
NEA = Problem=20 Statement (45 minutes)
Proposed NEA Charter=20 (45 minutes)
Consensus Check and=20 Volunteering (25 minutes)
 
The goal of the=20 NEA BOF is to confirm rough consensus on the NEA problem statement, on = the=20 importance of forming an IETF Working Group to address the problems = described in=20 that document, and on the proposed charter for such a Working Group. = Further,=20 the NEA BOF will verify that there are enough participants to make the = NEA=20 effort a success.
 
NEA BOF = participants are=20 expected to have read the documents listed below before the BOF meeting. = Discussion of these documents before the BOF meeting is strongly=20 encouraged. It will take place = on the=20 nea@ietf.org mailing lis
 
Proposed NEA=20 Charter
<Link to Proposed NEA = Charter>
 
Network=20 Endpoint Assessment (NEA) Problem = Statement
<Link to=20 draft-thomson-nea-problem-statement-00.txt>
= ------_=_NextPart_001_01C6267A.A2E5A723-- --===============0871919868== 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 --===============0871919868==-- From nea-bounces@ietf.org Tue Jan 31 10:26:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xP4-0004dL-A4; Tue, 31 Jan 2006 10:26:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xP1-0004Yv-OW for nea@megatron.ietf.org; Tue, 31 Jan 2006 10:26:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26589 for ; Tue, 31 Jan 2006 10:25:02 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3xZw-0007Q2-7t for nea@ietf.org; Tue, 31 Jan 2006 10:38:00 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2006 07:26:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,239,1136188800"; d="scan'208,217"; a="20871338:sNHT42446848" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0VFPnPq003909; Tue, 31 Jan 2006 10:26:25 -0500 (EST) 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.211); Tue, 31 Jan 2006 10:26:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 31 Jan 2006 10:26:21 -0500 Message-ID: Thread-Topic: Draft NEA WG charter: Please review Thread-Index: AcYmerCojRMY6f2QQ5CseRDWgkJveg== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 31 Jan 2006 15:26:22.0693 (UTC) FILETIME=[B12BA150:01C6267A] X-Spam-Score: 0.5 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: Steve Hanna Subject: [Nea] Draft NEA WG charter: Please review 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="===============0185987366==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0185987366== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6267A.B0E050D5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6267A.B0E050D5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. =20 The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). =20 The scope of the initial charter is on the following protocols that support architectures for network endpoint assessment (as described in draft-thomson-nea-problem-statement-00.txt): =20 1. IF-PB (posture broker protocol) 2. IF-PT (EAP method suitable for carrying posture information as well as supporting authentication) 3. IF-PT (EAP over IP transport protocol) 4. IF-NAE (Radius attributes for network access enforcement) =20 Other interfaces that may be included in the charter at a later date include: --- IF-PA (posture attribute protocol) --- IF-SB (Protocol between server broker and posture server. Name of interface TBD in problem-statement I-D. ) =20 Note that the initial scope of the WG targets architectures that use the EAP/Radius framework for IF-PT (posture transport interface) and IF-NAE (network access enforcement interface). This does not preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the initial charter. =20 Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs to identify the appropriate WG for meeting these requirements. =20 Milestones: =20 June 2006: * Submit requirements I-D to IETF including=20 --- requirements for IF-PT (EAP method layer)=20 --- requirements for IF-NAE=20 =20 September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over TLS) --- requirements for IF-PB =20 December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. =20 Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB * Submit I-D on protocols to be defined in this WG e.g. IF-PB specification ------_=_NextPart_001_01C6267A.B0E050D5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Architectures have=20 been implemented in the industry to assess the software or hardware = configuration of endpoint devices for the purposes of monitoring or = enforcing compliance of endpoints to an organization's policy for = access to=20 the network. These architectures are not fully interoperable = since some of=20 the protocols used to implement the architecture are not=20 standards.
 
The = first purpose of=20 the proposed working group is to define requirements for the protocols = needed to=20 ensure interoperability in an NEA system. The second purpose of the = working=20 group is to ensure standardization of protocols that meet these=20 requirements. In some cases, = these=20 protocols may best be standardized in another working group. Therefore, = the=20 proposed working group will work with the area directors to determine = the best=20 way to complete this standardization effort (in the proposed working = group or in=20 another one).
 
The scope of=20 the initial charter is on the following protocols that support = architectures for=20 network endpoint assessment (as=20 described in=20 draft-thomson-nea-problem-statement-00.txt):<= /SPAN>
 
1. = IF-PB (posture=20 broker protocol)
2. = IF-PT (EAP=20 method suitable for = carrying posture=20 information as well as supporting=20 authentication)
3. = IF-PT (EAP over=20 IP transport = protocol)
4. = IF-NAE (Radius=20 attributes for network access enforcement)
 
Other = interfaces=20  that may be included in the charter at a later date=20 include:
--- IF-PA=20 (posture attribute protocol)
--- IF-SB (Protocol between server broker and = posture=20 server. Name of interface TBD in problem-statement=20 I-D. )
 
Note that the=20 initial scope of the WG targets architectures that use the EAP/Radius = framework=20 for IF-PT (posture transport interface) and IF-NAE (network access = enforcement=20 interface). This does not preclude the=20 standardization of other posture transport protocols or network authorization = protocols in=20 the future, but this is not part of the initial=20 charter.
 
Work = will be carried=20 out in two phases. In the first phase, the=20 WG will define requirements for each of the protocols identified in 1) - 4) = above. When=20 the requirements have been defined, this WG=20 will work with the responsible ADs to identify the = appropriate=20 WG for meeting these=20 requirements.
 
Milestones:
 
June 2006:
* = Submit=20 requirements I-D to IETF  including 
--- requirements for IF-PT (EAP method layer)
--- requirements for IF-NAE
 
September=20 2006:
* = Submit revised=20 requirements I-D to IETF that includes above = plus:
--- = requirements=20 for IF -PT (EAP over IP=20 transport layer e.g. = EAP over=20 UDP, EAP over TLS)
--- = requirements=20 for IF-PB
 
December 2006:=20
* = Review ongoing=20 work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs = to=20 identify the WG responsible for accommodating protocol requirements that = are not=20 currently being met.
 
Feb=20 2007:
* = Submit =20 requirements I-D to IESG for publication as Info RFC
* = Revise WG charter=20 to accommodate definition of protocols not covered in other WGs e.g. = IF-PB
* = Submit I-D=20 on  protocols to be defined in this WG e.g. IF-PB=20 specification
------_=_NextPart_001_01C6267A.B0E050D5-- --===============0185987366== 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 --===============0185987366==-- From nea-bounces@ietf.org Tue Jan 31 11:08:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3y3E-0007C6-K1; Tue, 31 Jan 2006 11:08:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3y3C-0007AT-7R for nea@megatron.ietf.org; Tue, 31 Jan 2006 11:08:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00153 for ; Tue, 31 Jan 2006 11:06:27 -0500 (EST) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3yDy-0000TR-LD for nea@ietf.org; Tue, 31 Jan 2006 11:19:26 -0500 Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net [16.92.1.76]) by palrel11.hp.com (Postfix) with ESMTP id 94F3935D94; Tue, 31 Jan 2006 08:07:46 -0800 (PST) Received: from cacexc08.americas.cpqcorp.net ([16.92.1.35]) by cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 08:07:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Draft NEA WG charter: Please review Date: Tue, 31 Jan 2006 08:07:42 -0800 Message-ID: Thread-Topic: [Nea] Draft NEA WG charter: Please review Thread-Index: AcYmerCojRMY6f2QQ5CseRDWgkJvegABMYwg From: "Sanchez, Mauricio (PNB Roseville)" To: "Susan Thomson (sethomso)" , X-OriginalArrivalTime: 31 Jan 2006 16:07:43.0988 (UTC) FILETIME=[78233340:01C62680] X-Spam-Score: 0.6 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: Steve Hanna 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="===============1448527363==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1448527363== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62680.77E3AFDE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62680.77E3AFDE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Good beginning... =20 Couple comments/questions: =20 -How do protocols #2 and #3 differ if both are called out as being IF-PT. May lead to confusion. We may want to consider just calling out IF-PT once and placing various requirements that the single protocol must meet rather than breaking them out to seem like they're two protocols.=20 =20 -What is the rationale behind the selected milestone dates? In other words, why did you pick those dates and not others (perhaps by being more aggressive and pulling them in)? =20 - Why would December 2006's milestone not be done in conjunction with the prior two milestones? Waiting until 12/2006 to get the ball rolling on protocols seems like a long wait.=20 =20 Cheers, MS ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Tuesday, January 31, 2006 7:26 AM To: nea@ietf.org Cc: Steve Hanna Subject: [Nea] Draft NEA WG charter: Please review =09 =09 Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. =20 The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). =20 The scope of the initial charter is on the following protocols that support architectures for network endpoint assessment (as described in draft-thomson-nea-problem-statement-00.txt): =20 1. IF-PB (posture broker protocol) 2. IF-PT (EAP method suitable for carrying posture information as well as supporting authentication) 3. IF-PT (EAP over IP transport protocol) 4. IF-NAE (Radius attributes for network access enforcement) =20 Other interfaces that may be included in the charter at a later date include: --- IF-PA (posture attribute protocol) --- IF-SB (Protocol between server broker and posture server. Name of interface TBD in problem-statement I-D. ) =20 =09 Note that the initial scope of the WG targets architectures that use the EAP/Radius framework for IF-PT (posture transport interface) and IF-NAE (network access enforcement interface). This does not preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the initial charter. =20 Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs to identify the appropriate WG for meeting these requirements. =20 Milestones: =20 June 2006: * Submit requirements I-D to IETF including=20 --- requirements for IF-PT (EAP method layer)=20 --- requirements for IF-NAE=20 =20 September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over TLS) --- requirements for IF-PB =20 December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. =20 Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB * Submit I-D on protocols to be defined in this WG e.g. IF-PB specification ------_=_NextPart_001_01C62680.77E3AFDE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Good beginning...
 
Couple comments/questions:
 
-How do protocols #2 and #3 differ if both = are called=20 out as being IF-PT.  May lead to confusion.  We may want to = consider=20 just calling out IF-PT once and placing various requirements that the = single=20 protocol must meet rather than breaking them out to seem like they're = two=20 protocols.
 
-What is the rationale behind the selected = milestone dates?=20 In other words, why did you pick those dates and not others (perhaps by = being=20 more aggressive and pulling them in)?
 
- Why would December 2006's milestone not be = done in=20 conjunction with the prior two milestones?  Waiting until 12/2006 = to get=20 the ball rolling on protocols seems like a long wait. =
 
Cheers,
MS

From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson=20 (sethomso)
Sent: Tuesday, January 31, 2006 7:26 = AM
To:=20 nea@ietf.org
Cc: Steve Hanna
Subject: [Nea] Draft = NEA WG=20 charter: Please review

Architectures have=20 been implemented in the industry to assess the software or = hardware=20 configuration of endpoint devices for the purposes of monitoring = or=20 enforcing compliance of endpoints to an organization's policy for = access=20 to the network. These architectures are not fully interoperable=20 since some of the protocols used to implement the architecture = are not=20 standards.
 
The = first purpose=20 of the proposed working group is to define requirements for the = protocols=20 needed to ensure interoperability in an NEA system. The second purpose = of the=20 working group is to ensure standardization of protocols that meet = these=20 requirements. In some cases, = these=20 protocols may best be standardized in another working group. = Therefore, the=20 proposed working group will work with the area directors to determine = the best=20 way to complete this standardization effort (in the proposed working = group or=20 in another one).
 
The scope of=20 the initial charter is on the following protocols that support = architectures for=20 network endpoint assessment (as=20 described in=20 = draft-thomson-nea-problem-statement-00.txt):<= /SPAN>
 
1. = IF-PB (posture=20 broker protocol)
2. = IF-PT (EAP=20 method suitable for = carrying=20 posture information as well as = supporting=20 authentication)
3. = IF-PT (EAP over=20 IP transport=20 protocol)
4. = IF-NAE (Radius=20 attributes for network access enforcement)
 
Other interfaces=20  that may be included in the charter at a later date=20 include:
--- IF-PA=20 (posture attribute protocol)
--- IF-SB=20 (Protocol between server = broker and=20 posture server. Name of interface = TBD in problem-statement=20 I-D. )
 
Note that=20 the initial scope of the WG targets architectures that use the = EAP/Radius=20 framework for IF-PT (posture transport interface) and IF-NAE (network = access=20 enforcement interface). This does not preclude the standardization of other = posture=20 transport protocols or network = authorization protocols in the future,=20 but this is not part of the = initial=20 charter.
 
Work = will be=20 carried out in two phases. In the first phase, the WG will define = requirements for each=20 of the protocols = identified in 1) -=20 4) above. When the requirements have been defined, this WG will work with the responsible ADs=20 to identify the appropriate WG for meeting these=20 requirements.
 
Milestones:
 
June 2006:
* = Submit=20 requirements I-D to IETF =  including 
--- requirements for IF-PT (EAP method layer)
--- requirements for IF-NAE
 
September=20 2006:
* = Submit revised=20 requirements I-D to IETF that includes above = plus:
--- = requirements=20 for IF -PT (EAP over IP=20 transport layer = e.g. EAP=20 over UDP, EAP over TLS)
--- = requirements=20 for IF-PB
 
December 2006:=20
* = Review ongoing=20 work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with = ADs to=20 identify the WG responsible for accommodating protocol requirements = that are=20 not currently being met.
 
Feb=20 2007:
* = Submit =20 requirements I-D to IESG for publication as Info = RFC
* = Revise WG=20 charter to accommodate definition of protocols not covered = in other WGs e.g. = IF-PB
* = Submit I-D=20 on  protocols to be defined in this WG e.g. IF-PB=20 specification
------_=_NextPart_001_01C62680.77E3AFDE-- --===============1448527363== 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 --===============1448527363==-- From nea-bounces@ietf.org Tue Jan 31 12:27:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zHZ-0003bJ-2K; Tue, 31 Jan 2006 12:27:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zHW-0003YV-Ss for nea@megatron.ietf.org; Tue, 31 Jan 2006 12:27:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09004 for ; Tue, 31 Jan 2006 12:25:26 -0500 (EST) Received: from mail.signacert.com ([207.162.214.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3zSR-0004Bj-PP for nea@ietf.org; Tue, 31 Jan 2006 12:38:24 -0500 Received: from SCTHOMASTP42 (c-67-161-47-160.hsd1.ca.comcast.net [67.161.47.160]) by mail.signacert.com (Postfix) with ESMTP id AF21618EC45E; Tue, 31 Jan 2006 09:26:33 -0800 (PST) From: "Thomas Hardjono" To: "'Susan Thomson (sethomso)'" , Subject: RE: [Nea] Draft NEA WG charter: Please review Date: Tue, 31 Jan 2006 09:26:32 -0800 Organization: SignaCert Message-ID: <003a01c6268b$7b3d6a90$650110ac@SCTHOMASTP42> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYmerCojRMY6f2QQ5CseRDWgkJvegADk6Wg In-Reply-To: X-Spam-Score: 0.7 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Cc: 'Steve Hanna' , "'Hardjono, Thomas'" X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: THardjono@SignaCert.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1026514528==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1026514528== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C62648.6D1A2A90" This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C62648.6D1A2A90 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The Charter looks great. One nit: if interoperability is the target, perhaps one of the items that maybe useful is a standard structure for the posture information being sent from the NEA-Agent to the NEA-Server. Thus, not only should NEA define the *type* of pipe (the "how") that extends between the NEA-Plugin and NEA-Posture-Server, but also *what* kinds of meaningful stuff flows between the two end-points. This would allow true cross-vendor interoperability of NEA-Agents and NEA-Servers products (from differing H/W vendors and S/W ISVs). Looking at the proposed charter, the EAP-Method in IF-PT could include this work item. However, usually when the EAP WG talks about EAP-methods it doesn't specifically include semantically-rich posture reports. Does this make sense? cheers, /thomas/ _____ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Tuesday, January 31, 2006 7:26 AM To: nea@ietf.org Cc: Steve Hanna Subject: [Nea] Draft NEA WG charter: Please review Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). The scope of the initial charter is on the following protocols that support architectures for network endpoint assessment (as described in draft-thomson-nea-problem-statement-00.txt): 1. IF-PB (posture broker protocol) 2. IF-PT (EAP method suitable for carrying posture information as well as supporting authentication) 3. IF-PT (EAP over IP transport protocol) 4. IF-NAE (Radius attributes for network access enforcement) Other interfaces that may be included in the charter at a later date include: --- IF-PA (posture attribute protocol) --- IF-SB (Protocol between server broker and posture server. Name of interface TBD in problem-statement I-D. ) Note that the initial scope of the WG targets architectures that use the EAP/Radius framework for IF-PT (posture transport interface) and IF-NAE (network access enforcement interface). This does not preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the initial charter. Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs to identify the appropriate WG for meeting these requirements. Milestones: June 2006: * Submit requirements I-D to IETF including --- requirements for IF-PT (EAP method layer) --- requirements for IF-NAE September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over TLS) --- requirements for IF-PB December 2006: * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB * Submit I-D on protocols to be defined in this WG e.g. IF-PB specification ------=_NextPart_000_003B_01C62648.6D1A2A90 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
The Charter looks = great.
 
One nit:  if interoperability is the = target, perhaps=20 one of the items that maybe useful is a standard structure for the = posture=20 information being sent from the NEA-Agent to the = NEA-Server.
 
Thus, not only should NEA define the *type* of = pipe (the=20 "how") that extends between the NEA-Plugin and NEA-Posture-Server, = but also=20 *what* kinds of meaningful stuff flows between the two=20 end-points.
 
This would allow true cross-vendor = interoperability=20 of NEA-Agents and NEA-Servers products (from differing H/W vendors = and S/W=20 ISVs).
 
Looking at the proposed charter, the EAP-Method = in IF-PT=20 could include this work item.  However, usually when the EAP WG = talks about=20 EAP-methods it doesn't specifically include semantically-rich posture=20 reports.
 
Does this make sense?
 
cheers,
 
/thomas/
 

From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson=20 (sethomso)
Sent: Tuesday, January 31, 2006 7:26 = AM
To:=20 nea@ietf.org
Cc: Steve Hanna
Subject: [Nea] Draft = NEA WG=20 charter: Please review

Architectures have=20 been implemented in the industry to assess the software or hardware = configuration of endpoint devices for the purposes of monitoring or = enforcing compliance of endpoints to an organization's policy for = access to=20 the network. These architectures are not fully interoperable = since some of=20 the protocols used to implement the architecture are not=20 standards.
 
The = first purpose of=20 the proposed working group is to define requirements for the protocols = needed to=20 ensure interoperability in an NEA system. The second purpose of the = working=20 group is to ensure standardization of protocols that meet these=20 requirements. In some cases, = these=20 protocols may best be standardized in another working group. Therefore, = the=20 proposed working group will work with the area directors to determine = the best=20 way to complete this standardization effort (in the proposed working = group or in=20 another one).
 
The scope of=20 the initial charter is on the following protocols that support = architectures for=20 network endpoint assessment (as=20 described in=20 draft-thomson-nea-problem-statement-00.txt):<= /SPAN>
 
1. = IF-PB (posture=20 broker protocol)
2. = IF-PT (EAP=20 method suitable for = carrying posture=20 information as well as supporting=20 authentication)
3. = IF-PT (EAP over=20 IP transport = protocol)
4. = IF-NAE (Radius=20 attributes for network access enforcement)
 
Other = interfaces=20  that may be included in the charter at a later date=20 include:
--- IF-PA=20 (posture attribute protocol)
--- IF-SB (Protocol between server broker and = posture=20 server. Name of interface TBD in problem-statement=20 I-D. )
 
Note that the=20 initial scope of the WG targets architectures that use the EAP/Radius = framework=20 for IF-PT (posture transport interface) and IF-NAE (network access = enforcement=20 interface). This does not preclude the=20 standardization of other posture transport protocols or network authorization = protocols in=20 the future, but this is not part of the initial=20 charter.
 
Work = will be carried=20 out in two phases. In the first phase, the=20 WG will define requirements for each of the protocols identified in 1) - 4) = above. When=20 the requirements have been defined, this WG=20 will work with the responsible ADs to identify the = appropriate=20 WG for meeting these=20 requirements.
 
Milestones:
 
June 2006:
* = Submit=20 requirements I-D to IETF  including 
--- requirements for IF-PT (EAP method layer)
--- requirements for IF-NAE
 
September=20 2006:
* = Submit revised=20 requirements I-D to IETF that includes above = plus:
--- = requirements=20 for IF -PT (EAP over IP=20 transport layer e.g. = EAP over=20 UDP, EAP over TLS)
--- = requirements=20 for IF-PB
 
December 2006:=20
* = Review ongoing=20 work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs = to=20 identify the WG responsible for accommodating protocol requirements that = are not=20 currently being met.
 
Feb=20 2007:
* = Submit =20 requirements I-D to IESG for publication as Info RFC
* = Revise WG charter=20 to accommodate definition of protocols not covered in other WGs e.g. = IF-PB
* = Submit I-D=20 on  protocols to be defined in this WG e.g. IF-PB=20 specification
------=_NextPart_000_003B_01C62648.6D1A2A90-- --===============1026514528== 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 --===============1026514528==-- From nea-bounces@ietf.org Tue Jan 31 12:33:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zNV-0005VX-Pl; Tue, 31 Jan 2006 12:33:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zNS-0005ST-5u for nea@megatron.ietf.org; Tue, 31 Jan 2006 12:33:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09950 for ; Tue, 31 Jan 2006 12:31:30 -0500 (EST) 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 1F3zYG-0004ZX-3f for nea@ietf.org; Tue, 31 Jan 2006 12:44:28 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2006 09:32:51 -0800 X-IronPort-AV: i="4.01,240,1136188800"; d="scan'208,217"; a="398775401:sNHT61161754" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0VHWmWV018709; Tue, 31 Jan 2006 09:32:51 -0800 (PST) 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.211); Tue, 31 Jan 2006 12:32:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Draft NEA WG charter: Please review Date: Tue, 31 Jan 2006 12:32:49 -0500 Message-ID: Thread-Topic: [Nea] Draft NEA WG charter: Please review Thread-Index: AcYmerCojRMY6f2QQ5CseRDWgkJvegABMYwgAACxa6A= From: "Susan Thomson \(sethomso\)" To: "Sanchez, Mauricio \(PNB Roseville\)" , X-OriginalArrivalTime: 31 Jan 2006 17:32:50.0848 (UTC) FILETIME=[5C103200:01C6268C] X-Spam-Score: 0.6 (/) X-Scan-Signature: 847361531d5cb2b89126844012e81b58 Cc: Steve Hanna 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="===============1884057271==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1884057271== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6268C.5B9EECB9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6268C.5B9EECB9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thanks for the quick turnaround. Inline ... ________________________________ From: Sanchez, Mauricio (PNB Roseville) [mailto:mauricio.sanchez@hp.com]=20 Sent: Tuesday, January 31, 2006 11:08 AM To: Susan Thomson (sethomso); nea@ietf.org Cc: Steve Hanna Subject: RE: [Nea] Draft NEA WG charter: Please review =09 =09 =20 Good beginning... =20 Couple comments/questions: =20 -How do protocols #2 and #3 differ if both are called out as being IF-PT. May lead to confusion. We may want to consider just calling out IF-PT once and placing various requirements that the single protocol must meet rather than breaking them out to seem like they're two protocols.=20 =09 [Susan] Yes, the fact that this may lead to confusion crossed my mind as well. The current definition of IF-PT in problem statement I-D is quite general, the intent being (I believe) to cover a broad range of underlying technologies.=20 =20 But in the case of the EAP infrastructure (which is the scope we are talking about here), it covers a number of different protocol layers: EAP method e.g. some EAP tunneling method, EAP protocol itself, and EAP transport e.g. 802.1x, some flavor of EAP over IP. These are all separable protocols, addressed in various working groups both inside and outside the IETF. So we do need to separate out the protocols and their requirements. However, we may want to re-think the naming scheme. =20 I would propose that we leave this as is for the initial BOF request on Friday so that it is consistent with the naming used in -00 version of the problem-statement I-D. We can revisit this in the -01 version and then update the charter to match. =20 =20 -What is the rationale behind the selected milestone dates? In other words, why did you pick those dates and not others (perhaps by being more aggressive and pulling them in)? =09 [Susan] There is always a tension between being aggressive and being realistic! I think this WG may be somewhat more challenging than normal given its broad scope and the need for cross-area, cross-WG collaboration. As it stands, the milestones only give us 2 IETF meetings to wrap up all the requirements in the intial scope assuming this BOF is successful in March. If we can complete before then, great. But I would not bank on it. =20 - Why would December 2006's milestone not be done in conjunction with the prior two milestones? Waiting until 12/2006 to get the ball rolling on protocols seems like a long wait.=20 =09 [Susan] So the intent was not that we need to wait till then for any protocol work to proceed, but rather this is an official checkpoint with ADs of where we think we are in terms of doing any necessary re-chartering or other planning based on the requirements specified. In fact, there is some protocol work already underway e.g. Radius attribute definition in Radext WG, and the start of standardizing EAP methods in the EMU WG. The NEA WG would indeed need to be reviewing related work in other WGs while the requirements are being drawn up, to provide any heads-up and course corrections as soon as possible. =20 Hope this makes sense. Thanks Susan =20 Cheers, MS ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Tuesday, January 31, 2006 7:26 AM To: nea@ietf.org Cc: Steve Hanna Subject: [Nea] Draft NEA WG charter: Please review =09 =09 Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. =20 The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). =20 The scope of the initial charter is on the following protocols that support architectures for network endpoint assessment (as described in draft-thomson-nea-problem-statement-00.txt): =20 1. IF-PB (posture broker protocol) 2. IF-PT (EAP method suitable for carrying posture information as well as supporting authentication) 3. IF-PT (EAP over IP transport protocol) 4. IF-NAE (Radius attributes for network access enforcement) =20 Other interfaces that may be included in the charter at a later date include: --- IF-PA (posture attribute protocol) --- IF-SB (Protocol between server broker and posture server. Name of interface TBD in problem-statement I-D. ) =20 =09 Note that the initial scope of the WG targets architectures that use the EAP/Radius framework for IF-PT (posture transport interface) and IF-NAE (network access enforcement interface). This does not preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the initial charter. =20 Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs to identify the appropriate WG for meeting these requirements. =20 Milestones: =20 June 2006: * Submit requirements I-D to IETF including=20 --- requirements for IF-PT (EAP method layer)=20 --- requirements for IF-NAE=20 =20 September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over TLS) --- requirements for IF-PB =20 December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. =20 Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB * Submit I-D on protocols to be defined in this WG e.g. IF-PB specification ------_=_NextPart_001_01C6268C.5B9EECB9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Thanks for the quick turnaround. Inline=20 ...

From: Sanchez, Mauricio (PNB = Roseville)=20 [mailto:mauricio.sanchez@hp.com]
Sent: Tuesday, January 31, = 2006=20 11:08 AM
To: Susan Thomson (sethomso); = nea@ietf.org
Cc:=20 Steve Hanna
Subject: RE: [Nea] Draft NEA WG charter: Please=20 review

 
Good beginning...
 
Couple = comments/questions:
 
-How do protocols #2 and #3 differ = if both are=20 called out as being IF-PT.  May lead to confusion.  We may = want to=20 consider just calling out IF-PT once and placing various requirements = that the=20 single protocol must meet rather than breaking them out to seem like = they're=20 two protocols.
[Susan] Yes, the fact = that this may=20 lead to confusion crossed my mind as well. The current definition = of=20 IF-PT in problem statement I-D is quite general, the intent being (I = believe)=20 to cover a broad range of underlying technologies.=20
 
But in the case of the EAP=20 infrastructure (which is the scope we are talking about here), it = covers a=20 number of different protocol layers: EAP method e.g. some EAP = tunneling=20 method, EAP protocol itself, and EAP transport e.g. 802.1x, some = flavor of EAP=20 over IP. These are all separable protocols, addressed in various = working=20 groups both inside and outside the IETF. So we do need to separate out = the=20 protocols  and their requirements. However, we may want=20 to re-think the naming scheme.
 
I would propose that we = leave this as is=20 for the initial BOF request on Friday so that it is consistent with = the naming=20 used  in -00 version of the problem-statement I-D. We can revisit = this in=20 the -01 version and then update the charter to=20 match.
 
 
-What is the rationale behind the = selected=20 milestone dates? In other words, why did you pick those dates and not = others=20 (perhaps by being more aggressive and pulling them in)?
[Susan]  There is = always a=20 tension between being aggressive and being realistic! I think = this WG may=20 be somewhat more challenging than normal given its broad scope = and the=20 need for cross-area, cross-WG collaboration. As it stands, the = milestones only=20 give us 2 IETF meetings to wrap up all the requirements in the intial = scope=20 assuming this BOF is successful in March. If we can complete before = then,=20 great. But I would not bank on it.
 
- Why would December 2006's milestone = not be done=20 in conjunction with the prior two milestones?  Waiting until = 12/2006 to=20 get the ball rolling on protocols seems like a long wait.
[Susan]  So the intent was not that we need = to wait=20 till then for any protocol work to proceed, but rather this is an = official=20 checkpoint with ADs of where we think we are in terms of doing any = necessary=20 re-chartering or other planning based on the requirements specified. = In fact,=20 there is some protocol work already underway e.g. Radius attribute = definition=20 in Radext WG, and the start of standardizing EAP methods in the EMU = WG. The=20 NEA WG would indeed need to be reviewing related work in other WGs = while the=20 requirements are being drawn up, to provide any heads-up and course=20 corrections as soon as = possible.
 
Hope this = makes=20 sense.
Thanks
Susan
 
Cheers,
MS

From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson=20 (sethomso)
Sent: Tuesday, January 31, 2006 7:26 = AM
To:=20 nea@ietf.org
Cc: Steve Hanna
Subject: [Nea] = Draft NEA WG=20 charter: Please review

Architectures=20 have been implemented in the industry to assess the software or = hardware configuration of endpoint devices for the purposes of=20 monitoring or enforcing compliance of endpoints to an=20 organization's policy for access to the network. These = architectures=20 are not fully interoperable since some of the protocols used to = implement the architecture are not standards.
 
The first=20 purpose of the proposed working group is to define requirements for = the=20 protocols needed to ensure interoperability in an NEA system. The = second=20 purpose of the working group is to ensure standardization of = protocols that=20 meet these requirements. In = some=20 cases, these protocols may best be standardized in another working = group.=20 Therefore, the proposed working group will work with the area = directors to=20 determine the best way to complete this standardization effort (in = the=20 proposed working group or in another one).
 
The scope=20 of the initial charter is on the following protocols that support=20 architectures for network endpoint assessment (as described in=20 = draft-thomson-nea-problem-statement-00.txt):<= /SPAN>
 
1. = IF-PB=20 (posture broker protocol)
2. = IF-PT (EAP=20 method suitable for = carrying=20 posture information as well as = supporting=20 authentication)
3. = IF-PT (EAP=20 over IP transport=20 protocol)
4. = IF-NAE=20 (Radius attributes for network access = enforcement)
 
Other interfaces=20  that may be included in the charter at a later date=20 include:
--- IF-PA=20 (posture attribute protocol)
--- IF-SB=20 (Protocol between server = broker and=20 posture server. Name of interface = TBD in problem-statement=20 I-D. )
 
Note that=20 the initial scope of the WG targets architectures that use the = EAP/Radius=20 framework for IF-PT (posture transport interface) and IF-NAE = (network access=20 enforcement interface). This does not preclude the standardization of other = posture=20 transport protocols or = network=20 authorization protocols in the future,=20 but this is not part of the = initial=20 charter.
 
Work will be=20 carried out in two phases. In the first phase, the WG will define = requirements for=20 each of the protocols = identified=20 in 1) - 4) above. When the requirements have been = defined, this WG will work with the responsible = ADs=20 to identify the appropriate WG for meeting these=20 requirements.
 
Milestones:
 
June 2006:
* = Submit=20 requirements I-D to IETF =  including 
--- requirements for IF-PT (EAP = method layer) =
--- requirements for IF-NAE
 
September=20 2006:
* = Submit revised=20 requirements I-D to IETF that includes above = plus:
--- requirements=20 for IF -PT (EAP over IP=20 transport layer = e.g. EAP=20 over UDP, EAP over TLS)
--- requirements=20 for IF-PB
 
December 2006:=20
* = Review ongoing=20 work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with = ADs to=20 identify the WG responsible for accommodating protocol requirements = that are=20 not currently being met.
 
Feb=20 2007:
* = Submit =20 requirements I-D to IESG for publication as Info = RFC
* = Revise WG=20 charter to accommodate definition of protocols not covered = in other WGs e.g. = IF-PB
* = Submit I-D=20 on  protocols to be defined in this WG e.g. IF-PB=20 = specification
<= /HTML> ------_=_NextPart_001_01C6268C.5B9EECB9-- --===============1884057271== 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 --===============1884057271==-- From nea-bounces@ietf.org Tue Jan 31 12:56:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zjz-0004Gn-TD; Tue, 31 Jan 2006 12:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zjx-0004FS-WF for nea@megatron.ietf.org; Tue, 31 Jan 2006 12:56:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12968 for ; Tue, 31 Jan 2006 12:54:36 -0500 (EST) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3zue-0005nM-1o for nea@ietf.org; Tue, 31 Jan 2006 13:07:35 -0500 Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net [16.92.1.76]) by palrel11.hp.com (Postfix) with ESMTP id 5BDAC374AC; Tue, 31 Jan 2006 09:55:57 -0800 (PST) Received: from cacexc08.americas.cpqcorp.net ([16.92.1.35]) by cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 09:55:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Draft NEA WG charter: Please review Date: Tue, 31 Jan 2006 09:55:53 -0800 Message-ID: Thread-Topic: [Nea] Draft NEA WG charter: Please review Thread-Index: AcYmerCojRMY6f2QQ5CseRDWgkJvegABMYwgAACxa6AAA1EXgA== From: "Sanchez, Mauricio (PNB Roseville)" To: "Susan Thomson (sethomso)" , X-OriginalArrivalTime: 31 Jan 2006 17:55:54.0613 (UTC) FILETIME=[94D9FA50:01C6268F] X-Spam-Score: 0.6 (/) X-Scan-Signature: bb8d68e55b48f2ff3cebd1a6416d9536 Cc: Steve Hanna 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="===============0823793132==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0823793132== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6268F.94670D9A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6268F.94670D9A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Okay...sounds like there are appropriate plans in place. =20 MS ________________________________ From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 Sent: Tuesday, January 31, 2006 9:33 AM To: Sanchez, Mauricio (PNB Roseville); nea@ietf.org Cc: Steve Hanna Subject: RE: [Nea] Draft NEA WG charter: Please review =09 =09 Thanks for the quick turnaround. Inline ... ________________________________ From: Sanchez, Mauricio (PNB Roseville) [mailto:mauricio.sanchez@hp.com]=20 Sent: Tuesday, January 31, 2006 11:08 AM To: Susan Thomson (sethomso); nea@ietf.org Cc: Steve Hanna Subject: RE: [Nea] Draft NEA WG charter: Please review =09 =09 =20 Good beginning... =20 Couple comments/questions: =20 -How do protocols #2 and #3 differ if both are called out as being IF-PT. May lead to confusion. We may want to consider just calling out IF-PT once and placing various requirements that the single protocol must meet rather than breaking them out to seem like they're two protocols.=20 =09 [Susan] Yes, the fact that this may lead to confusion crossed my mind as well. The current definition of IF-PT in problem statement I-D is quite general, the intent being (I believe) to cover a broad range of underlying technologies.=20 =20 But in the case of the EAP infrastructure (which is the scope we are talking about here), it covers a number of different protocol layers: EAP method e.g. some EAP tunneling method, EAP protocol itself, and EAP transport e.g. 802.1x, some flavor of EAP over IP. These are all separable protocols, addressed in various working groups both inside and outside the IETF. So we do need to separate out the protocols and their requirements. However, we may want to re-think the naming scheme. =20 I would propose that we leave this as is for the initial BOF request on Friday so that it is consistent with the naming used in -00 version of the problem-statement I-D. We can revisit this in the -01 version and then update the charter to match. =20 =20 -What is the rationale behind the selected milestone dates? In other words, why did you pick those dates and not others (perhaps by being more aggressive and pulling them in)? =09 [Susan] There is always a tension between being aggressive and being realistic! I think this WG may be somewhat more challenging than normal given its broad scope and the need for cross-area, cross-WG collaboration. As it stands, the milestones only give us 2 IETF meetings to wrap up all the requirements in the intial scope assuming this BOF is successful in March. If we can complete before then, great. But I would not bank on it. =20 - Why would December 2006's milestone not be done in conjunction with the prior two milestones? Waiting until 12/2006 to get the ball rolling on protocols seems like a long wait.=20 =09 [Susan] So the intent was not that we need to wait till then for any protocol work to proceed, but rather this is an official checkpoint with ADs of where we think we are in terms of doing any necessary re-chartering or other planning based on the requirements specified. In fact, there is some protocol work already underway e.g. Radius attribute definition in Radext WG, and the start of standardizing EAP methods in the EMU WG. The NEA WG would indeed need to be reviewing related work in other WGs while the requirements are being drawn up, to provide any heads-up and course corrections as soon as possible. =20 Hope this makes sense. Thanks Susan =20 Cheers, MS ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Tuesday, January 31, 2006 7:26 AM To: nea@ietf.org Cc: Steve Hanna Subject: [Nea] Draft NEA WG charter: Please review =09 =09 Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. =20 The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). =20 The scope of the initial charter is on the following protocols that support architectures for network endpoint assessment (as described in draft-thomson-nea-problem-statement-00.txt): =20 1. IF-PB (posture broker protocol) 2. IF-PT (EAP method suitable for carrying posture information as well as supporting authentication) 3. IF-PT (EAP over IP transport protocol) 4. IF-NAE (Radius attributes for network access enforcement) =20 Other interfaces that may be included in the charter at a later date include: --- IF-PA (posture attribute protocol) --- IF-SB (Protocol between server broker and posture server. Name of interface TBD in problem-statement I-D. ) =20 =09 Note that the initial scope of the WG targets architectures that use the EAP/Radius framework for IF-PT (posture transport interface) and IF-NAE (network access enforcement interface). This does not preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the initial charter. =20 Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs to identify the appropriate WG for meeting these requirements. =20 Milestones: =20 June 2006: * Submit requirements I-D to IETF including=20 --- requirements for IF-PT (EAP method layer)=20 --- requirements for IF-NAE=20 =20 September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over TLS) --- requirements for IF-PB =20 December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. =20 Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB * Submit I-D on protocols to be defined in this WG e.g. IF-PB specification ------_=_NextPart_001_01C6268F.94670D9A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Okay...sounds like there are appropriate plans = in=20 place.
 
MS

From: Susan Thomson (sethomso)=20 [mailto:sethomso@cisco.com]
Sent: Tuesday, January 31, 2006 = 9:33=20 AM
To: Sanchez, Mauricio (PNB Roseville); = nea@ietf.org
Cc:=20 Steve Hanna
Subject: RE: [Nea] Draft NEA WG charter: Please=20 review

Thanks for the quick turnaround. Inline=20 ...

From: Sanchez, Mauricio (PNB = Roseville)=20 [mailto:mauricio.sanchez@hp.com]
Sent: Tuesday, January = 31, 2006=20 11:08 AM
To: Susan Thomson (sethomso); = nea@ietf.org
Cc:=20 Steve Hanna
Subject: RE: [Nea] Draft NEA WG charter: = Please=20 review

 
Good beginning...
 
Couple = comments/questions:
 
-How do = protocols #2 and #3=20 differ if both are called out as being IF-PT.  May lead to=20 confusion.  We may want to consider just calling out IF-PT once = and=20 placing various requirements that the single protocol must meet = rather than=20 breaking them out to seem like they're two protocols.
[Susan] Yes, the fact=20 that this may lead to confusion crossed my mind as well. The = current=20 definition of IF-PT in problem statement I-D is quite general, the = intent=20 being (I believe) to cover a broad range of underlying technologies. =
 
But in the = case of the EAP=20 infrastructure (which is the scope we are talking about here), it = covers a=20 number of different protocol layers: EAP method e.g. some EAP = tunneling=20 method, EAP protocol itself, and EAP transport e.g. 802.1x, some = flavor of=20 EAP over IP. These are all separable protocols, addressed in various = working=20 groups both inside and outside the IETF. So we do need to separate = out the=20 protocols  and their requirements. However, we may want=20 to re-think the naming = scheme.
 
I would = propose that we=20 leave this as is for the initial BOF request on Friday so that it is = consistent with the naming used  in -00 version of the=20 problem-statement I-D. We can revisit this in the -01 version and = then=20 update the charter to match.
 
 
-What is the = rationale behind=20 the selected milestone dates? In other words, why did you pick those = dates=20 and not others (perhaps by being more aggressive and pulling them=20 in)?
[Susan]  There is=20 always a tension between being aggressive and being realistic! = I think=20 this WG may be somewhat more challenging than normal given its = broad=20 scope and the need for cross-area, cross-WG collaboration. As it = stands, the=20 milestones only give us 2 IETF meetings to wrap up all the = requirements in=20 the intial scope assuming this BOF is successful in March. If we can = complete before then, great. But I would not bank on=20 it.
 
- Why would = December 2006's=20 milestone not be done in conjunction with the prior two = milestones? =20 Waiting until 12/2006 to get the ball rolling on protocols seems = like a long=20 wait.
[Susan]  So the intent was not that we = need to wait=20 till then for any protocol work to proceed, but rather this is an = official=20 checkpoint with ADs of where we think we are in terms of doing any = necessary=20 re-chartering or other planning based on the requirements specified. = In=20 fact, there is some protocol work already underway e.g. Radius = attribute=20 definition in Radext WG, and the start of standardizing EAP methods = in the=20 EMU WG. The NEA WG would indeed need to be reviewing related work in = other=20 WGs while the requirements are being drawn up, to provide any = heads-up and=20 course corrections as soon as=20 possible.
 
Hope this=20 makes sense.
Thanks
Susan
 
Cheers,
MS

From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson=20 (sethomso)
Sent: Tuesday, January 31, 2006 7:26 = AM
To:=20 nea@ietf.org
Cc: Steve Hanna
Subject: [Nea] = Draft NEA=20 WG charter: Please review

Architectures=20 have been implemented in the industry to assess the software = or=20 hardware configuration of endpoint devices for the purposes = of=20 monitoring or enforcing compliance of endpoints to an=20 organization's policy for access to the network. These = architectures=20 are not fully interoperable since some of the protocols used = to=20 implement the architecture are not standards.
 
The first=20 purpose of the proposed working group is to define requirements = for the=20 protocols needed to ensure interoperability in an NEA system. The = second=20 purpose of the working group is to ensure standardization of = protocols=20 that meet these requirements. = In=20 some cases, these protocols may best be standardized in another = working=20 group. Therefore, the proposed working group will work with the = area=20 directors to determine the best way to complete this = standardization=20 effort (in the proposed working group or in another=20 one).
 
The=20 scope of the initial charter is on the following protocols that support=20 architectures for network endpoint assessment (as described in=20 = draft-thomson-nea-problem-statement-00.txt):<= /SPAN>
 
1. IF-PB=20 (posture broker protocol)
2. IF-PT (EAP=20 method suitable for = carrying=20 posture information as well as = supporting=20 authentication)
3. IF-PT (EAP=20 over IP transport=20 protocol)
4. IF-NAE=20 (Radius attributes for network access = enforcement)
 
Other=20 interfaces  that may be included in the charter at a later = date=20 include:
--- IF-PA=20 (posture attribute protocol)
--- IF-SB=20 (Protocol between server = broker and=20 posture server. Name of interface = TBD in problem-statement=20 I-D. )
 
Note=20 that the initial scope of the WG targets architectures that use = the=20 EAP/Radius framework for IF-PT (posture transport interface) and = IF-NAE=20 (network access enforcement interface). This does not = preclude the standardization = of other posture=20 transport protocols or = network=20 authorization protocols in the future,=20 but this is not part of = the initial=20 charter.
 
Work will be=20 carried out in two phases. In the first phase, the WG will define = requirements for=20 each of the protocols = identified in 1) - 4) above. When the requirements have been=20 defined, this WG will work = with the=20 responsible ADs to identify the appropriate = WG for meeting these=20 requirements.
 
Milestones:
 
June 2006:
* Submit=20 requirements I-D to IETF =  including 
--- requirements for IF-PT (EAP = method layer) =
--- requirements for IF-NAE =
 
September=20 2006:
* Submit=20 revised requirements I-D to IETF that includes above=20 plus:
---=20 requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP = over=20 TLS)
---=20 requirements for IF-PB
 
December 2006:=20
* Review=20 ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and = work=20 with ADs to identify the WG responsible for accommodating protocol = requirements that are not currently being met.
 
Feb=20 2007:
* Submit =20 requirements I-D to IESG for publication as Info = RFC
* Revise WG=20 charter to accommodate definition of protocols not covered = in other WGs e.g. = IF-PB
* Submit I-D=20 on  protocols to be defined in this WG e.g. IF-PB=20 = specification
------_=_NextPart_001_01C6268F.94670D9A-- --===============0823793132== 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 --===============0823793132==-- From nea-bounces@ietf.org Tue Jan 31 13:58:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40ha-0003sa-8E; Tue, 31 Jan 2006 13:58:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40hX-0003ro-O1 for nea@megatron.ietf.org; Tue, 31 Jan 2006 13:58:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19027 for ; Tue, 31 Jan 2006 13:56:22 -0500 (EST) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F40sR-0008KA-I9 for nea@ietf.org; Tue, 31 Jan 2006 14:09:22 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k0VIveEi026729 for ; Tue, 31 Jan 2006 18:57:40 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k0VIv8FG017123 for ; Tue, 31 Jan 2006 18:57:40 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006013110573922483 for ; Tue, 31 Jan 2006 10:57:40 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 10:57:33 -0800 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 10:57:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Draft NEA WG charter: Please review Date: Tue, 31 Jan 2006 13:55:12 -0500 Message-ID: <5404AEB459F8354F81995E038F34320002591ED2@hdsmsx401.amr.corp.intel.com> Thread-Topic: [Nea] Draft NEA WG charter: Please review Thread-Index: AcYmerCojRMY6f2QQ5CseRDWgkJvegABMYwgAACxa6AABUrtsA== From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 31 Jan 2006 18:57:33.0199 (UTC) FILETIME=[316169F0:01C62698] X-Scanned-By: MIMEDefang 2.52 on 10.253.24.20 X-Spam-Score: 0.9 (/) X-Scan-Signature: 713965ef965c5660ee5d9a664a73ef4a 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="===============0618194186==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0618194186== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62698.3087BE5B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62698.3087BE5B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sue, do you expect that the protocol (IF-PT) would be different depending on what carrier it's traveling over? =20 I won't want to upset the apple cart, so no objections for it going to BOF as is. But for the WG - perhaps we should reconsider. =20 Regarding the dates - I see Mauricio's point, but again - there's less of a problem completing before the specified date than dragging past it. Let's keep the milestones as they are. =20 =20 ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Tuesday, January 31, 2006 12:33 PM To: Sanchez, Mauricio (PNB Roseville); nea@ietf.org Cc: Steve Hanna Subject: RE: [Nea] Draft NEA WG charter: Please review Thanks for the quick turnaround. Inline ... ________________________________ From: Sanchez, Mauricio (PNB Roseville) [mailto:mauricio.sanchez@hp.com]=20 Sent: Tuesday, January 31, 2006 11:08 AM To: Susan Thomson (sethomso); nea@ietf.org Cc: Steve Hanna Subject: RE: [Nea] Draft NEA WG charter: Please review =09 =09 =20 Good beginning... =20 Couple comments/questions: =20 -How do protocols #2 and #3 differ if both are called out as being IF-PT. May lead to confusion. We may want to consider just calling out IF-PT once and placing various requirements that the single protocol must meet rather than breaking them out to seem like they're two protocols.=20 =09 [Susan] Yes, the fact that this may lead to confusion crossed my mind as well. The current definition of IF-PT in problem statement I-D is quite general, the intent being (I believe) to cover a broad range of underlying technologies.=20 =20 But in the case of the EAP infrastructure (which is the scope we are talking about here), it covers a number of different protocol layers: EAP method e.g. some EAP tunneling method, EAP protocol itself, and EAP transport e.g. 802.1x, some flavor of EAP over IP. These are all separable protocols, addressed in various working groups both inside and outside the IETF. So we do need to separate out the protocols and their requirements. However, we may want to re-think the naming scheme. =20 I would propose that we leave this as is for the initial BOF request on Friday so that it is consistent with the naming used in -00 version of the problem-statement I-D. We can revisit this in the -01 version and then update the charter to match. =20 =20 -What is the rationale behind the selected milestone dates? In other words, why did you pick those dates and not others (perhaps by being more aggressive and pulling them in)? =09 [Susan] There is always a tension between being aggressive and being realistic! I think this WG may be somewhat more challenging than normal given its broad scope and the need for cross-area, cross-WG collaboration. As it stands, the milestones only give us 2 IETF meetings to wrap up all the requirements in the intial scope assuming this BOF is successful in March. If we can complete before then, great. But I would not bank on it. =20 - Why would December 2006's milestone not be done in conjunction with the prior two milestones? Waiting until 12/2006 to get the ball rolling on protocols seems like a long wait.=20 =09 [Susan] So the intent was not that we need to wait till then for any protocol work to proceed, but rather this is an official checkpoint with ADs of where we think we are in terms of doing any necessary re-chartering or other planning based on the requirements specified. In fact, there is some protocol work already underway e.g. Radius attribute definition in Radext WG, and the start of standardizing EAP methods in the EMU WG. The NEA WG would indeed need to be reviewing related work in other WGs while the requirements are being drawn up, to provide any heads-up and course corrections as soon as possible. =20 Hope this makes sense. Thanks Susan =20 Cheers, MS ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Tuesday, January 31, 2006 7:26 AM To: nea@ietf.org Cc: Steve Hanna Subject: [Nea] Draft NEA WG charter: Please review =09 =09 Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. =20 The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). =20 The scope of the initial charter is on the following protocols that support architectures for network endpoint assessment (as described in draft-thomson-nea-problem-statement-00.txt): =20 1. IF-PB (posture broker protocol) 2. IF-PT (EAP method suitable for carrying posture information as well as supporting authentication) 3. IF-PT (EAP over IP transport protocol) 4. IF-NAE (Radius attributes for network access enforcement) =20 Other interfaces that may be included in the charter at a later date include: --- IF-PA (posture attribute protocol) --- IF-SB (Protocol between server broker and posture server. Name of interface TBD in problem-statement I-D. ) =20 =09 Note that the initial scope of the WG targets architectures that use the EAP/Radius framework for IF-PT (posture transport interface) and IF-NAE (network access enforcement interface). This does not preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the initial charter. =20 Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs to identify the appropriate WG for meeting these requirements. =20 Milestones: =20 June 2006: * Submit requirements I-D to IETF including=20 --- requirements for IF-PT (EAP method layer)=20 --- requirements for IF-NAE=20 =20 September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over TLS) --- requirements for IF-PB =20 December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. =20 Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB * Submit I-D on protocols to be defined in this WG e.g. IF-PB specification ------_=_NextPart_001_01C62698.3087BE5B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sue, =20 do you expect that the protocol (IF-PT) would be different depending on = what=20 carrier it's traveling over?
 
I won't=20 want to upset the apple cart, so no objections for it going to BOF as = is. But=20 for the WG - perhaps we should reconsider.
 
Regarding=20 the dates - I see Mauricio's point, but again - there's less = of a=20 problem completing before the specified date than dragging past = it. Let's=20 keep the milestones as they are.
 
 
From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson=20 (sethomso)
Sent: Tuesday, January 31, 2006 12:33 = PM
To:=20 Sanchez, Mauricio (PNB Roseville); nea@ietf.org
Cc: Steve=20 Hanna
Subject: RE: [Nea] Draft NEA WG charter: Please=20 review

Thanks for the quick turnaround. Inline=20 ...

From: Sanchez, Mauricio (PNB = Roseville)=20 [mailto:mauricio.sanchez@hp.com]
Sent: Tuesday, January = 31, 2006=20 11:08 AM
To: Susan Thomson (sethomso); = nea@ietf.org
Cc:=20 Steve Hanna
Subject: RE: [Nea] Draft NEA WG charter: = Please=20 review

 
Good beginning...
 
Couple = comments/questions:
 
-How do = protocols #2 and #3=20 differ if both are called out as being IF-PT.  May lead to=20 confusion.  We may want to consider just calling out IF-PT once = and=20 placing various requirements that the single protocol must meet = rather than=20 breaking them out to seem like they're two protocols.
[Susan] Yes, the fact=20 that this may lead to confusion crossed my mind as well. The = current=20 definition of IF-PT in problem statement I-D is quite general, the = intent=20 being (I believe) to cover a broad range of underlying technologies. =
 
But in the = case of the EAP=20 infrastructure (which is the scope we are talking about here), it = covers a=20 number of different protocol layers: EAP method e.g. some EAP = tunneling=20 method, EAP protocol itself, and EAP transport e.g. 802.1x, some = flavor of=20 EAP over IP. These are all separable protocols, addressed in various = working=20 groups both inside and outside the IETF. So we do need to separate = out the=20 protocols  and their requirements. However, we may want=20 to re-think the naming = scheme.
 
I would = propose that we=20 leave this as is for the initial BOF request on Friday so that it is = consistent with the naming used  in -00 version of the=20 problem-statement I-D. We can revisit this in the -01 version and = then=20 update the charter to match.
 
 
-What is the = rationale behind=20 the selected milestone dates? In other words, why did you pick those = dates=20 and not others (perhaps by being more aggressive and pulling them=20 in)?
[Susan]  There is=20 always a tension between being aggressive and being realistic! = I think=20 this WG may be somewhat more challenging than normal given its = broad=20 scope and the need for cross-area, cross-WG collaboration. As it = stands, the=20 milestones only give us 2 IETF meetings to wrap up all the = requirements in=20 the intial scope assuming this BOF is successful in March. If we can = complete before then, great. But I would not bank on=20 it.
 
- Why would = December 2006's=20 milestone not be done in conjunction with the prior two = milestones? =20 Waiting until 12/2006 to get the ball rolling on protocols seems = like a long=20 wait.
[Susan]  So the intent was not that we = need to wait=20 till then for any protocol work to proceed, but rather this is an = official=20 checkpoint with ADs of where we think we are in terms of doing any = necessary=20 re-chartering or other planning based on the requirements specified. = In=20 fact, there is some protocol work already underway e.g. Radius = attribute=20 definition in Radext WG, and the start of standardizing EAP methods = in the=20 EMU WG. The NEA WG would indeed need to be reviewing related work in = other=20 WGs while the requirements are being drawn up, to provide any = heads-up and=20 course corrections as soon as=20 possible.
 
Hope this=20 makes sense.
Thanks
Susan
 
Cheers,
MS

From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson=20 (sethomso)
Sent: Tuesday, January 31, 2006 7:26 = AM
To:=20 nea@ietf.org
Cc: Steve Hanna
Subject: [Nea] = Draft NEA=20 WG charter: Please review

Architectures=20 have been implemented in the industry to assess the software = or=20 hardware configuration of endpoint devices for the purposes = of=20 monitoring or enforcing compliance of endpoints to an=20 organization's policy for access to the network. These = architectures=20 are not fully interoperable since some of the protocols used = to=20 implement the architecture are not standards.
 
The first=20 purpose of the proposed working group is to define requirements = for the=20 protocols needed to ensure interoperability in an NEA system. The = second=20 purpose of the working group is to ensure standardization of = protocols=20 that meet these requirements. = In=20 some cases, these protocols may best be standardized in another = working=20 group. Therefore, the proposed working group will work with the = area=20 directors to determine the best way to complete this = standardization=20 effort (in the proposed working group or in another=20 one).
 
The=20 scope of the initial charter is on the following protocols that support=20 architectures for network endpoint assessment (as described in=20 = draft-thomson-nea-problem-statement-00.txt):<= /SPAN>
 
1. IF-PB=20 (posture broker protocol)
2. IF-PT (EAP=20 method suitable for = carrying=20 posture information as well as = supporting=20 authentication)
3. IF-PT (EAP=20 over IP transport=20 protocol)
4. IF-NAE=20 (Radius attributes for network access = enforcement)
 
Other=20 interfaces  that may be included in the charter at a later = date=20 include:
--- IF-PA=20 (posture attribute protocol)
--- IF-SB=20 (Protocol between server = broker and=20 posture server. Name of interface = TBD in problem-statement=20 I-D. )
 
Note=20 that the initial scope of the WG targets architectures that use = the=20 EAP/Radius framework for IF-PT (posture transport interface) and = IF-NAE=20 (network access enforcement interface). This does not = preclude the standardization = of other posture=20 transport protocols or = network=20 authorization protocols in the future,=20 but this is not part of = the initial=20 charter.
 
Work will be=20 carried out in two phases. In the first phase, the WG will define = requirements for=20 each of the protocols = identified in 1) - 4) above. When the requirements have been=20 defined, this WG will work = with the=20 responsible ADs to identify the appropriate = WG for meeting these=20 requirements.
 
Milestones:
 
June 2006:
* Submit=20 requirements I-D to IETF =  including 
--- requirements for IF-PT (EAP = method layer) =
--- requirements for IF-NAE =
 
September=20 2006:
* Submit=20 revised requirements I-D to IETF that includes above=20 plus:
---=20 requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP = over=20 TLS)
---=20 requirements for IF-PB
 
December 2006:=20
* Review=20 ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and = work=20 with ADs to identify the WG responsible for accommodating protocol = requirements that are not currently being met.
 
Feb=20 2007:
* Submit =20 requirements I-D to IESG for publication as Info = RFC
* Revise WG=20 charter to accommodate definition of protocols not covered = in other WGs e.g. = IF-PB
* Submit I-D=20 on  protocols to be defined in this WG e.g. IF-PB=20 = specification
------_=_NextPart_001_01C62698.3087BE5B-- --===============0618194186== 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 --===============0618194186==-- From nea-bounces@ietf.org Tue Jan 31 14:36:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41J1-0007C4-PQ; Tue, 31 Jan 2006 14:36:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41Iy-00079q-7J for nea@megatron.ietf.org; Tue, 31 Jan 2006 14:36:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21740 for ; Tue, 31 Jan 2006 14:34:57 -0500 (EST) Received: from us-rws-mail1.ipass.com ([216.239.96.50] helo=mail1.ipass.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F41Tn-0001br-Cz for nea@ietf.org; Tue, 31 Jan 2006 14:47:58 -0500 Received: from 10.10.4.74 by mail1.ipass.com with ESMTP (iPass Inc.); Tue, 31 Jan 2006 19:35:59 -0000 X-Server-Uuid: 8E3B2B66-D3E4-4B8B-9313-10C820E76A89 Received: from EXCHANGE3.corp.ipass.com ([10.10.4.138]) by exchange2.corp.ipass.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 11:35:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Draft NEA WG charter: Please review Date: Tue, 31 Jan 2006 11:35:59 -0800 Message-ID: Thread-Topic: [Nea] Draft NEA WG charter: Please review Thread-Index: AcYmerCojRMY6f2QQ5CseRDWgkJvegADk6WgAATjc0A= From: "Barbara Nelson" To: THardjono@SignaCert.com, "Susan Thomson (sethomso)" , nea@ietf.org X-OriginalArrivalTime: 31 Jan 2006 19:35:59.0967 (UTC) FILETIME=[905246F0:01C6269D] X-WSS-ID: 6FC163952A41030316-01-01 X-Spam-Score: 0.3 (/) X-Scan-Signature: 142968907492cd6b805bce4edf0aec7b Cc: Steve Hanna , "Hardjono, Thomas" 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="===============1536936515==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1536936515== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6269D.9035DDD9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6269D.9035DDD9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I think we need to bound the scope of interoperability, or we'll give ourselves an impossible problem to solve. Trying to get "industry-standard semantically-rich" posture reports feels like an unachievable goal. Trying to get an NEA agent broker from one vendor and an NEA server broker from another vendor to successfully exchange reports seems a more achievable goal. I'd like us to first focus on the transport mechanism between the agent and the server, and if we have success in standardizing that, then we can move on to standardizing some forms of posture reports. =20 Barbara. =20 ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Thomas Hardjono Sent: Tuesday, January 31, 2006 9:27 AM To: 'Susan Thomson (sethomso)'; nea@ietf.org Cc: 'Steve Hanna'; 'Hardjono, Thomas' Subject: RE: [Nea] Draft NEA WG charter: Please review =20 The Charter looks great. =20 One nit: if interoperability is the target, perhaps one of the items that maybe useful is a standard structure for the posture information being sent from the NEA-Agent to the NEA-Server. =20 Thus, not only should NEA define the *type* of pipe (the "how") that extends between the NEA-Plugin and NEA-Posture-Server, but also *what* kinds of meaningful stuff flows between the two end-points. =20 This would allow true cross-vendor interoperability of NEA-Agents and NEA-Servers products (from differing H/W vendors and S/W ISVs). =20 Looking at the proposed charter, the EAP-Method in IF-PT could include this work item. However, usually when the EAP WG talks about EAP-methods it doesn't specifically include semantically-rich posture reports. =20 Does this make sense? =20 cheers, =20 /thomas/ =20 =20 ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Tuesday, January 31, 2006 7:26 AM To: nea@ietf.org Cc: Steve Hanna Subject: [Nea] Draft NEA WG charter: Please review Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. =20 The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). =20 The scope of the initial charter is on the following protocols that support architectures for network endpoint assessment (as described in draft-thomson-nea-problem-statement-00.txt): =20 1. IF-PB (posture broker protocol) 2. IF-PT (EAP method suitable for carrying posture information as well as supporting authentication) 3. IF-PT (EAP over IP transport protocol) 4. IF-NAE (Radius attributes for network access enforcement) =20 Other interfaces that may be included in the charter at a later date include: --- IF-PA (posture attribute protocol) --- IF-SB (Protocol between server broker and posture server. Name of interface TBD in problem-statement I-D. ) =20 Note that the initial scope of the WG targets architectures that use the EAP/Radius framework for IF-PT (posture transport interface) and IF-NAE (network access enforcement interface). This does not preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the initial charter. =20 Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs to identify the appropriate WG for meeting these requirements. =20 Milestones: =20 June 2006: * Submit requirements I-D to IETF including=20 --- requirements for IF-PT (EAP method layer)=20 --- requirements for IF-NAE=20 =20 September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over TLS) --- requirements for IF-PB =20 December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. =20 Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB * Submit I-D on protocols to be defined in this WG e.g. IF-PB specification ------_=_NextPart_001_01C6269D.9035DDD9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

I think we need to bound the scope = of interoperability, or we’ll give ourselves an impossible problem to = solve.  Trying to get “industry-standard semantically-rich” = posture reports feels like an unachievable goal.  Trying to get an NEA = agent broker from one vendor and an NEA server broker from another vendor to successfully = exchange reports seems a more achievable goal.  I’d like us to first = focus on the transport mechanism between the agent and the server, and if we have = success in standardizing that, then we can move on to standardizing some forms of = posture reports.

 

Barbara.

 

From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Thomas Hardjono
Sent: Tuesday, January = 31, 2006 9:27 AM
To: 'Susan Thomson = (sethomso)'; nea@ietf.org
Cc: 'Steve Hanna'; = 'Hardjono, Thomas'
Subject: RE: [Nea] Draft = NEA WG charter: Please review

 

The Charter looks great.

 

One = nit:  if interoperability is the target, perhaps one of the items that maybe = useful is a standard structure for the posture information being sent from the = NEA-Agent to the NEA-Server.

 

Thus, = not only should NEA define the *type* of pipe (the "how") that = extends between the NEA-Plugin and NEA-Posture-Server, but also *what* kinds of meaningful stuff flows between the two = end-points.

 

This = would allow true cross-vendor interoperability of NEA-Agents and NEA-Servers = products (from differing H/W vendors and S/W ISVs).

 

Looking = at the proposed charter, the EAP-Method in IF-PT could include this work = item.  However, usually when the EAP WG talks about EAP-methods it doesn't specifically include semantically-rich posture = reports.

 

Does = this make sense?

 

cheers,

 

/thomas/

 

 

From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso)
Sent: Tuesday, January = 31, 2006 7:26 AM
To: nea@ietf.org
Cc: Steve Hanna
Subject: [Nea] Draft NEA = WG charter: Please review

Architectures have been implemented in the industry = to assess the software or hardware configuration of endpoint = devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These = architectures are not fully interoperable since some of the protocols used to = implement the architecture are not standards.

 

The first purpose of the proposed working group is to = define requirements for the protocols needed to ensure interoperability in an = NEA system. The second purpose of the working group is to ensure = standardization of protocols that meet these requirements. In some cases, these protocols = may best be standardized in another working group. Therefore, the proposed = working group will work with the area directors to determine the best way to complete = this standardization effort (in the proposed working group or in another = one).

 

The scope of the initial charter is on the following protocols that support architectures for network endpoint = assessment (as described in = draft-thomson-nea-problem-statement-00.txt):

=

 

1. IF-PB (posture = broker protocol)

2. IF-PT (EAP method suitable for carrying = posture information as well as supporting = authentication)

3. IF-PT (EAP over IP transport = protocol)

4. IF-NAE (Radius attributes for network access = enforcement)

 

Other interfaces  that may be included in the = charter at a later date include:

--- IF-PA (posture = attribute protocol)

--- IF-SB (Protocol between server broker and = posture server. Name of interface TBD in problem-statement = I-D. )

 

Note that the initial scope of the WG targets = architectures that use the EAP/Radius framework for IF-PT (posture transport = interface) and IF-NAE (network access enforcement interface). This does not = preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the = initial charter.

 

Work will be carried out in two phases. In the first phase, the WG will define requirements for each of = the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs = to identify the appropriate WG for meeting these = requirements.

 

Milestones:

 

June 2006:

* Submit requirements I-D to IETF =  including 

--- requirements for IF-PT (EAP method layer) =

--- requirements for IF-NAE =

 

September 2006:

* Submit revised requirements I-D to IETF that = includes above plus:

--- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over = TLS)

--- requirements = for IF-PB

 

December 2006:

* Review ongoing work in IETF (e.g. EMU WG, Radext = WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for = accommodating protocol requirements that are not currently being = met.

 

Feb 2007:

* Submit  requirements I-D to IESG for = publication as Info RFC

* Revise WG charter to accommodate definition of = protocols not covered in other WGs e.g. IF-PB

* Submit I-D on  protocols to be defined in = this WG e.g. IF-PB specification

------_=_NextPart_001_01C6269D.9035DDD9-- --===============1536936515== 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 --===============1536936515==-- From nea-bounces@ietf.org Tue Jan 31 14:46:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41Sp-0001gC-Jp; Tue, 31 Jan 2006 14:46:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41Sn-0001dU-IU for nea@megatron.ietf.org; Tue, 31 Jan 2006 14:46:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22417 for ; Tue, 31 Jan 2006 14:45:09 -0500 (EST) Received: from ogo.signacert.com ([207.162.214.7] helo=mail.signacert.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F41dg-0001wI-Kd for nea@ietf.org; Tue, 31 Jan 2006 14:58:09 -0500 Received: from SCTHOMASTP42 (c-67-161-47-160.hsd1.ca.comcast.net [67.161.47.160]) by mail.signacert.com (Postfix) with ESMTP id 366B118EC45E; Tue, 31 Jan 2006 11:46:29 -0800 (PST) From: "Thomas Hardjono" To: "'Barbara Nelson'" , "'Susan Thomson (sethomso)'" , Subject: RE: [Nea] Draft NEA WG charter: Please review Date: Tue, 31 Jan 2006 11:46:28 -0800 Organization: SignaCert Message-ID: <007b01c6269f$075ae210$650110ac@SCTHOMASTP42> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYmerCojRMY6f2QQ5CseRDWgkJvegADk6WgAATjc0AAAGsJ0A== In-Reply-To: X-Spam-Score: 0.5 (/) X-Scan-Signature: f31e050dc7ce62aeed70903f7da21012 Cc: 'Steve Hanna' , "'Hardjono, Thomas'" X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: THardjono@SignaCert.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0393227161==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0393227161== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C6265B.F937A210" This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C6265B.F937A210 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sure, I think that's a reasonable timeline/phases to follow. Working on a standard transport mechanism (i.e. IF-PT and/or IF-PB) is more challenging. (PS. I'm thinking that currently a vendor [e.g. AV vendor] needs to implement both sides of the handshake across IF-PA. Thus pretty much interoperability with only itself:) cheers, /thomas/ _____ From: Barbara Nelson [mailto:bnelson@ipass.com] Sent: Tuesday, January 31, 2006 11:36 AM To: THardjono@SignaCert.com; Susan Thomson (sethomso); nea@ietf.org Cc: Steve Hanna; Hardjono, Thomas Subject: RE: [Nea] Draft NEA WG charter: Please review I think we need to bound the scope of interoperability, or we'll give ourselves an impossible problem to solve. Trying to get "industry-standard semantically-rich" posture reports feels like an unachievable goal. Trying to get an NEA agent broker from one vendor and an NEA server broker from another vendor to successfully exchange reports seems a more achievable goal. I'd like us to first focus on the transport mechanism between the agent and the server, and if we have success in standardizing that, then we can move on to standardizing some forms of posture reports. Barbara. _____ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Thomas Hardjono Sent: Tuesday, January 31, 2006 9:27 AM To: 'Susan Thomson (sethomso)'; nea@ietf.org Cc: 'Steve Hanna'; 'Hardjono, Thomas' Subject: RE: [Nea] Draft NEA WG charter: Please review The Charter looks great. One nit: if interoperability is the target, perhaps one of the items that maybe useful is a standard structure for the posture information being sent from the NEA-Agent to the NEA-Server. Thus, not only should NEA define the *type* of pipe (the "how") that extends between the NEA-Plugin and NEA-Posture-Server, but also *what* kinds of meaningful stuff flows between the two end-points. This would allow true cross-vendor interoperability of NEA-Agents and NEA-Servers products (from differing H/W vendors and S/W ISVs). Looking at the proposed charter, the EAP-Method in IF-PT could include this work item. However, usually when the EAP WG talks about EAP-methods it doesn't specifically include semantically-rich posture reports. Does this make sense? cheers, /thomas/ _____ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Tuesday, January 31, 2006 7:26 AM To: nea@ietf.org Cc: Steve Hanna Subject: [Nea] Draft NEA WG charter: Please review Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). The scope of the initial charter is on the following protocols that support architectures for network endpoint assessment (as described in draft-thomson-nea-problem-statement-00.txt): 1. IF-PB (posture broker protocol) 2. IF-PT (EAP method suitable for carrying posture information as well as supporting authentication) 3. IF-PT (EAP over IP transport protocol) 4. IF-NAE (Radius attributes for network access enforcement) Other interfaces that may be included in the charter at a later date include: --- IF-PA (posture attribute protocol) --- IF-SB (Protocol between server broker and posture server. Name of interface TBD in problem-statement I-D. ) Note that the initial scope of the WG targets architectures that use the EAP/Radius framework for IF-PT (posture transport interface) and IF-NAE (network access enforcement interface). This does not preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the initial charter. Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs to identify the appropriate WG for meeting these requirements. Milestones: June 2006: * Submit requirements I-D to IETF including --- requirements for IF-PT (EAP method layer) --- requirements for IF-NAE September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over TLS) --- requirements for IF-PB December 2006: * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB * Submit I-D on protocols to be defined in this WG e.g. IF-PB specification ------=_NextPart_000_007C_01C6265B.F937A210 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Sure, I think that's a reasonable = timeline/phases to=20 follow.  Working on a standard transport mechanism (i.e. IF-PT = and/or=20 IF-PB) is more challenging.
 
(PS. I'm thinking that currently a vendor [e.g. = AV vendor]=20 needs to implement both sides of the handshake across IF-PA. Thus pretty = much=20 interoperability with only itself:)
 
cheers,
 
/thomas/

From: Barbara Nelson = [mailto:bnelson@ipass.com]=20
Sent: Tuesday, January 31, 2006 11:36 AM
To:=20 THardjono@SignaCert.com; Susan Thomson (sethomso); = nea@ietf.org
Cc:=20 Steve Hanna; Hardjono, Thomas
Subject: RE: [Nea] Draft NEA WG = charter:=20 Please review

I think we = need to=20 bound the scope of interoperability, or we’ll give ourselves an = impossible=20 problem to solve.  Trying to get “industry-standard = semantically-rich”=20 posture reports feels like an unachievable goal.  Trying to get an = NEA=20 agent broker from one vendor and an NEA server broker from another = vendor to=20 successfully exchange reports seems a more achievable goal.  = I’d like us to=20 first focus on the transport mechanism between the agent and the server, = and if=20 we have success in standardizing that, then we can move on to = standardizing some=20 forms of posture reports.

 

Barbara.

 

From:=20 nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Thomas = Hardjono
Sent: Tuesday, January 31, 2006 = 9:27=20 AM
To: 'Susan Thomson = (sethomso)'; nea@ietf.org
Cc:=20 'Steve Hanna'; 'Hardjono, Thomas'
Subject: RE: [Nea] Draft NEA WG = charter:=20 Please review

 

The Charter=20 looks great.

 

One = nit: =20 if interoperability is the target, perhaps one of the items that maybe = useful is=20 a standard structure for the posture information being sent from the = NEA-Agent=20 to the NEA-Server.

 

Thus, = not only=20 should NEA define the *type* of pipe (the "how") that extends = between the=20 NEA-Plugin and NEA-Posture-Server, but also *what* kinds of meaningful = stuff=20 flows between the two end-points.

 

This = would=20 allow true cross-vendor interoperability of NEA-Agents and = NEA-Servers=20 products (from differing H/W vendors and S/W = ISVs).

 

Looking at the=20 proposed charter, the EAP-Method in IF-PT could include this work = item. =20 However, usually when the EAP WG talks about EAP-methods it doesn't = specifically=20 include semantically-rich posture reports.

 

Does = this make=20 sense?

 

cheers,

 

/thomas/

 

 

From:=20 nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson=20 (sethomso)
Sent: = Tuesday,=20 January 31, 2006 7:26 AM
To:=20 nea@ietf.org
Cc: = Steve=20 Hanna
Subject: [Nea] = Draft NEA=20 WG charter: Please review

Architectures have been = implemented=20 in the industry to assess the software or hardware = configuration of=20 endpoint devices for the purposes of monitoring or enforcing compliance = of=20 endpoints to an organization's policy for access to the network. = These=20 architectures are not fully interoperable since some of the = protocols used=20 to implement the architecture are not=20 standards.

 

The first purpose of the = proposed=20 working group is to define requirements for the protocols needed to = ensure=20 interoperability in an NEA system. The second purpose of the working = group is to=20 ensure standardization of protocols that meet these requirements. In = some cases,=20 these protocols may best be standardized in another working group. = Therefore,=20 the proposed working group will work with the area directors to = determine the=20 best way to complete this standardization effort (in the proposed = working group=20 or in another one).

 

The scope of the initial = charter is=20 on the following protocols that support architectures for network = endpoint=20 assessment (as described in=20 draft-thomson-nea-problem-statement-00.txt):

=

 

1. IF-PB (posture=20 broker protocol)

2. IF-PT (EAP = method suitable=20 for carrying posture information as well as supporting=20 authentication)

3. IF-PT (EAP over IP = transport=20 protocol)

4. IF-NAE (Radius = attributes for=20 network access enforcement)

 

Other interfaces =  that may be=20 included in the charter at a later date=20 include:

--- IF-PA (posture=20 attribute protocol)

--- IF-SB (Protocol = between=20 server broker and posture server. Name of interface TBD in = problem-statement=20 I-D. )

 

Note that the initial = scope of the=20 WG targets architectures that use the EAP/Radius framework for IF-PT = (posture=20 transport interface) and IF-NAE (network access enforcement interface). = This=20 does not preclude the standardization of other posture = transport=20 protocols or network authorization protocols in the future, but this is = not part=20 of the initial charter.

 

Work will be carried out = in two=20 phases. In the first phase, the WG will define = requirements for each=20 of the protocols identified in 1) - 4) above. When the = requirements=20 have been defined, this WG will work with the responsible ADs=20 to identify the appropriate WG for meeting these=20 requirements.

 

Milestones:

 

June 2006:

* Submit requirements = I-D to=20 IETF  including 

--- requirements for IF-PT = (EAP=20 method layer)

--- requirements for = IF-NAE=20

 

September=20 2006:

* Submit revised=20 requirements I-D to IETF that includes above=20 plus:

--- requirements = for IF -PT=20 (EAP over IP transport layer e.g. EAP over UDP, EAP over=20 TLS)

--- requirements=20 for IF-PB

 

December 2006:=20

* Review ongoing work in = IETF (e.g.=20 EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG = responsible for accommodating protocol requirements that are not = currently being=20 met.

 

Feb=20 2007:

* Submit  = requirements I-D to=20 IESG for publication as Info RFC

* Revise WG charter to = accommodate=20 definition of protocols not covered in other WGs e.g.=20 IF-PB

* Submit I-D = on  protocols=20 to be defined in this WG e.g. IF-PB=20 specification

------=_NextPart_000_007C_01C6265B.F937A210-- --===============0393227161== 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 --===============0393227161==-- From nea-bounces@ietf.org Tue Jan 31 17:34:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F445O-00077f-4g; Tue, 31 Jan 2006 17:34:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F445I-00076a-OZ for nea@megatron.ietf.org; Tue, 31 Jan 2006 17:34:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06004 for ; Tue, 31 Jan 2006 17:33:03 -0500 (EST) Received: from smtp.mail.umich.edu ([141.211.14.81] helo=hackers.mr.itd.umich.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F44GB-0000Tx-Eu for nea@ietf.org; Tue, 31 Jan 2006 17:46:04 -0500 Received: FROM [192.168.1.103] (24-247-31-156.dhcp.bycy.mi.charter.com [24.247.31.156]) BY hackers.mr.itd.umich.edu ID 43DFE39B.DE25C.1653 ; 31 Jan 2006 17:24:28 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <0D0E56C7-0AC5-4EC0-AD83-41EE49E5F309@umich.edu> From: John Vollbrecht Subject: Re: [Nea] Draft NEA WG charter: Please review Date: Tue, 31 Jan 2006 17:24:25 -0500 To: "Sanchez, Mauricio (PNB Roseville)" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.6 (/) X-Scan-Signature: 303e29529f30c23b95ea718537067fd5 Cc: Steve Hanna , 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="===============1556708522==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org --===============1556708522== Content-Type: multipart/alternative; boundary=Apple-Mail-2--622207740 --Apple-Mail-2--622207740 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I also think this is a good starting point. I tend to agree with Mauricio that it would be good to group the two IF-PT items or perhaps call them IF-PTa and IF-PTb. Regardless what you decide about this I think the proposed charter is excellent, and I assume can be refined a bit based on the BOF discussions. I am looking forward to working on this John On Jan 31, 2006, at 12:55 PM, Sanchez, Mauricio (PNB Roseville) wrote: > > Okay...sounds like there are appropriate plans in place. > > MS > > From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com] > Sent: Tuesday, January 31, 2006 9:33 AM > To: Sanchez, Mauricio (PNB Roseville); nea@ietf.org > Cc: Steve Hanna > Subject: RE: [Nea] Draft NEA WG charter: Please review > > Thanks for the quick turnaround. Inline ... > > From: Sanchez, Mauricio (PNB Roseville) > [mailto:mauricio.sanchez@hp.com] > Sent: Tuesday, January 31, 2006 11:08 AM > To: Susan Thomson (sethomso); nea@ietf.org > Cc: Steve Hanna > Subject: RE: [Nea] Draft NEA WG charter: Please review > > > Good beginning... > > Couple comments/questions: > > -How do protocols #2 and #3 differ if both are called out as being > IF-PT. May lead to confusion. We may want to consider just > calling out IF-PT once and placing various requirements that the > single protocol must meet rather than breaking them out to seem > like they're two protocols. > [Susan] Yes, the fact that this may lead to confusion crossed my > mind as well. The current definition of IF-PT in problem statement > I-D is quite general, the intent being (I believe) to cover a broad > range of underlying technologies. > > But in the case of the EAP infrastructure (which is the scope we > are talking about here), it covers a number of different protocol > layers: EAP method e.g. some EAP tunneling method, EAP protocol > itself, and EAP transport e.g. 802.1x, some flavor of EAP over IP. > These are all separable protocols, addressed in various working > groups both inside and outside the IETF. So we do need to separate > out the protocols and their requirements. However, we may want to > re-think the naming scheme. > > I would propose that we leave this as is for the initial BOF > request on Friday so that it is consistent with the naming used in > -00 version of the problem-statement I-D. We can revisit this in > the -01 version and then update the charter to match. > > > -What is the rationale behind the selected milestone dates? In > other words, why did you pick those dates and not others > (perhaps by being more aggressive and pulling them in)? > [Susan] There is always a tension between being aggressive and > being realistic! I think this WG may be somewhat more challenging > than normal given its broad scope and the need for cross-area, > cross-WG collaboration. As it stands, the milestones only give us 2 > IETF meetings to wrap up all the requirements in the intial scope > assuming this BOF is successful in March. If we can complete before > then, great. But I would not bank on it. > > - Why would December 2006's milestone not be done in conjunction > with the prior two milestones? Waiting until 12/2006 to get the > ball rolling on protocols seems like a long wait. > [Susan] So the intent was not that we need to wait till then for > any protocol work to proceed, but rather this is an official > checkpoint with ADs of where we think we are in terms of doing any > necessary re-chartering or other planning based on the requirements > specified. In fact, there is some protocol work already underway > e.g. Radius attribute definition in Radext WG, and the start of > standardizing EAP methods in the EMU WG. The NEA WG would indeed > need to be reviewing related work in other WGs while the > requirements are being drawn up, to provide any heads-up and course > corrections as soon as possible. > > Hope this makes sense. > Thanks > Susan > > Cheers, > MS > > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf > Of Susan Thomson (sethomso) > Sent: Tuesday, January 31, 2006 7:26 AM > To: nea@ietf.org > Cc: Steve Hanna > Subject: [Nea] Draft NEA WG charter: Please review > > Architectures have been implemented in the industry to assess the > software or hardware configuration of endpoint devices for the > purposes of monitoring or enforcing compliance of endpoints to an > organization's policy for access to the network. These > architectures are not fully interoperable since some of the > protocols used to implement the architecture are not standards. > > The first purpose of the proposed working group is to define > requirements for the protocols needed to ensure interoperability in > an NEA system. The second purpose of the working group is to ensure > standardization of protocols that meet these requirements. In some > cases, these protocols may best be standardized in another working > group. Therefore, the proposed working group will work with the > area directors to determine the best way to complete this > standardization effort (in the proposed working group or in another > one). > > The scope of the initial charter is on the following protocols that > support architectures for network endpoint assessment (as described > in draft-thomson-nea-problem-statement-00.txt): > > 1. IF-PB (posture broker protocol) > 2. IF-PT (EAP method suitable for carrying posture information as > well as supporting authentication) > 3. IF-PT (EAP over IP transport protocol) > 4. IF-NAE (Radius attributes for network access enforcement) > > Other interfaces that may be included in the charter at a later > date include: > --- IF-PA (posture attribute protocol) > --- IF-SB (Protocol between server broker and posture server. Name > of interface TBD in problem-statement I-D. ) > > Note that the initial scope of the WG targets architectures that > use the EAP/Radius framework for IF-PT (posture transport > interface) and IF-NAE (network access enforcement interface). This > does not preclude the standardization of other posture transport > protocols or network authorization protocols in the future, but > this is not part of the initial charter. > > Work will be carried out in two phases. In the first phase, the WG > will define requirements for each of the protocols identified in 1) > - 4) above. When the requirements have been defined, this WG will > work with the responsible ADs to identify the appropriate WG for > meeting these requirements. > > Milestones: > > June 2006: > * Submit requirements I-D to IETF including > --- requirements for IF-PT (EAP method layer) > --- requirements for IF-NAE > > September 2006: > * Submit revised requirements I-D to IETF that includes above plus: > --- requirements for IF -PT (EAP over IP transport layer e.g. EAP > over UDP, EAP over TLS) > --- requirements for IF-PB > > December 2006: > * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA > WG) and work with ADs to identify the WG responsible for > accommodating protocol requirements that are not currently being met. > > Feb 2007: > * Submit requirements I-D to IESG for publication as Info RFC > * Revise WG charter to accommodate definition of protocols not > covered in other WGs e.g. IF-PB > * Submit I-D on protocols to be defined in this WG e.g. IF-PB > specification > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea --Apple-Mail-2--622207740 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I also think this is a good = starting point.=A0 I tend to agree with Mauricio that it would be good = to group the two IF-PT items or perhaps call them IF-PTa and = IF-PTb.

Regardless = what you decide about this I think the proposed charter is excellent, = and I assume can be refined a bit based on the BOF = discussions.

I = am looking forward to working on this

John

= On Jan 31, 2006, at 12:55 PM, Sanchez, Mauricio (PNB Roseville) = wrote:

=A0
Okay...sounds like there are appropriate plans in = place.
=A0
MS

From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com] =
Sent: Tuesday, January 31, 2006 9:33 AM
To: = Sanchez, Mauricio (PNB Roseville); nea@ietf.org
Cc: Steve = Hanna
Subject: RE: [Nea] Draft NEA WG charter: Please = review

Thanks for the quick turnaround. Inline = ...

= From: Sanchez, Mauricio (PNB = Roseville) [mailto:mauricio.sanchez@hp.com= ]
Sent: Tuesday, January 31, 2006 11:08 AM
To: = Susan Thomson (sethomso); nea@ietf.org
Cc: Steve = Hanna
Subject: RE: [Nea] Draft NEA WG charter: Please = review

=A0
Good beginning...
=A0
Couple comments/questions:
=A0
=
-How=A0do = protocols #2 and #3 differ if both are called out as being IF-PT.=A0 = May lead to confusion.=A0 We may want to consider just calling out = IF-PT once and placing various requirements that the single protocol = must meet rather than breaking them out to seem like they're two = protocols.
=
[Susan]=A0Yes, the fact that this may = lead to confusion=A0crossed my mind as well. The current definition = of IF-PT in problem statement I-D is quite general, the intent being = (I believe) to cover a broad range of underlying technologies. =
=A0
=
But in the case of the EAP = infrastructure (which is the scope we are talking about here), it covers = a number of different protocol layers: EAP method e.g. some EAP = tunneling method, EAP protocol itself, and EAP transport e.g. = 802.1x, some flavor of EAP over IP. These are all separable = protocols, addressed in various working groups both inside and = outside the IETF. So we do need to separate out the protocols=A0=A0and= their requirements. However, we may want to=A0re-think the naming = scheme.
=A0
=
I would propose that we leave this as = is for the initial BOF request on Friday so that it is consistent = with the naming used =A0in -00 version of the problem-statement I-D. = We can revisit this in the -01 version and then update the charter = to match.
=A0
=
=A0
-What is the = rationale behind the selected milestone dates? In other words, why = did you pick those dates and not others (perhaps by being more = aggressive and pulling them in)?
=
[Susan]=A0=A0There is always a tension = between being aggressive and being=A0realistic! I think this WG may = be somewhat more challenging than=A0normal given its broad scope and = the need for cross-area, cross-WG collaboration. As it stands, the = milestones only give us 2 IETF meetings to wrap up all the requirements = in the intial scope assuming this BOF is successful in March. If we = can complete before then, great. But I would not bank on = it.
=A0
- Why would = December 2006's milestone not be done in conjunction with the prior = two milestones?=A0 Waiting until 12/2006 to get the ball rolling on = protocols seems like a long wait.
=
[Susan]=A0=A0So the = intent was not that we need to wait till then for any protocol work = to proceed, but rather this is an official checkpoint with ADs of = where we think we are in terms of doing any necessary re-chartering = or other planning based on the requirements specified. In fact, = there is some protocol work already underway e.g. Radius attribute = definition in Radext WG, and the start of standardizing EAP methods in = the EMU WG. The NEA WG would indeed need to be reviewing related = work in other WGs while the requirements are being drawn up, to = provide any heads-up and course corrections as soon as = possible.
=A0
=
Hope this makes = sense.
Thanks
=
Susan
=
=A0
=
Cheers,
=
MS

=
=
From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] = On Behalf Of Susan Thomson (sethomso)
Sent: = Tuesday, January 31, 2006 7:26 AM
To: nea@ietf.org
Cc: Steve = Hanna
Subject: [Nea] Draft NEA WG charter: Please = review

Architectures= have been implemented in the industry to assess the=A0software or = hardware configuration=A0of endpoint devices for the purposes of = monitoring or enforcing compliance of endpoints to an = organization's=A0policy for access to the network. These architectures = are not fully interoperable since=A0some of the protocols used to = implement the architecture are not standards.
=
=A0
The first = purpose of the proposed working group is to define requirements for = the protocols needed to ensure interoperability in an NEA system. = The second purpose of the working group is to ensure = standardization of protocols that meet these requirements. In some cases, these = protocols may best be standardized in another working group. = Therefore, the proposed working group will work with the area = directors to determine the best way to complete this standardization = effort (in the proposed working group or in another = one).
=
=A0
The = scope of the initial charter is on the following protocols that support = architectures=A0for network endpoint assessment (as described in = draft-thomson-nea-problem-statement-00.txt):
=A0
1. IF-PB = (posture broker=A0protocol)
=
2.= IF-PT (EAP method=A0suitable = for carrying posture information as well as supporting = authentication)
3. IF-PT (EAP over = IP transport = protocol)
4. IF-NAE (Radius = attributes for network access enforcement)
=
=A0
Other = interfaces =A0that may be included in the charter at a later date = include:
---=A0IF-PA (posture = attribute=A0protocol)
=
---=A0IF-SB (Protocol between server broker and = posture server. Name of interface = TBD in problem-statement = I-D.=A0)
=A0
Note = that the initial scope of the WG targets architectures that use the = EAP/Radius framework for IF-PT (posture transport interface) and = IF-NAE (network access enforcement interface). This does not = preclude=A0the standardization = of=A0other posture transport protocols or network = authorization protocols in the future, = but this is not part of = the initial = charter.
=A0
Work will = be carried out in two phases. In the first phase,=A0the WG will define requirements=A0for = each of the=A0protocols = identified in 1) - 4) above.=A0When the requirements have been = defined,=A0this WG will work with = the responsible ADs to=A0identify the appropriate WG=A0for meeting these = requirements.
=A0
=
Milestones:
=
=A0
June=A02006:
* Submit requirements I-D=A0to IETF = =A0including=A0
--- requirements for IF-PT (EAP method layer)
=
--- requirements for = IF-NAE =
=A0
=
September 2006:
=
* Submit revised requirements=A0I-D = to IETF that includes above plus:
=
--- requirements for=A0IF -PT (EAP = over=A0IP transport=A0layer e.g. EAP over UDP, EAP over = TLS)
--- requirements = for=A0IF-PB
=A0
=
December 2006:
=
* Review ongoing work in IETF (e.g. EMU WG, Radext WG, = PANA WG, NEA WG) and work with ADs to identify the WG responsible = for accommodating protocol requirements that are not currently = being met.
=A0
=
Feb 2007:
=
* = Submit=A0 requirements I-D to IESG for publication as Info = RFC
* Revise WG charter to accommodate = definition of protocols not covered in=A0other WGs e.g. = IF-PB
* Submit I-D on=A0=A0protocols to be = defined in this WG e.g. IF-PB = specification
Nea mailing list
=

= --Apple-Mail-2--622207740-- --===============1556708522== 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 --===============1556708522==-- From nea-bounces@ietf.org Tue Jan 31 17:50:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F44Kl-0003bJ-Ra; Tue, 31 Jan 2006 17:50:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F44Ki-0003Zg-5R for nea@megatron.ietf.org; Tue, 31 Jan 2006 17:50:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07461 for ; Tue, 31 Jan 2006 17:49:01 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F44Vd-00010r-EJ for nea@ietf.org; Tue, 31 Jan 2006 18:02:02 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 31 Jan 2006 17:50:25 -0500 X-IronPort-AV: i="4.01,242,1136178000"; d="scan'208,217"; a="81421776:sNHT4430630952" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0VMnwPi022691; Tue, 31 Jan 2006 17:50:22 -0500 (EST) 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.211); Tue, 31 Jan 2006 17:50:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Draft NEA WG charter: Please review Date: Tue, 31 Jan 2006 17:50:05 -0500 Message-ID: Thread-Topic: [Nea] Draft NEA WG charter: Please review Thread-Index: AcYmerCojRMY6f2QQ5CseRDWgkJvegABMYwgAACxa6AABUrtsAAH9ATg From: "Susan Thomson \(sethomso\)" To: "Blumenthal, Uri" , X-OriginalArrivalTime: 31 Jan 2006 22:50:07.0301 (UTC) FILETIME=[AEAC6750:01C626B8] X-Spam-Score: 0.6 (/) X-Scan-Signature: 7d6df83bcd4607742efc577a82719ecc 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="===============1963176324==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1963176324== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C626B8.AE5B7315" This is a multi-part message in MIME format. ------_=_NextPart_001_01C626B8.AE5B7315 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Blumenthal, Uri Sent: Tuesday, January 31, 2006 1:55 PM To: nea@ietf.org Subject: RE: [Nea] Draft NEA WG charter: Please review =09 =09 Sue, do you expect that the protocol (IF-PT) would be different depending on what carrier it's traveling over? [Susan]=20 When you say IF-PT do you mean the EAP method layer (e.g. an EAP tunneling method), versus the EAP underlying transport (e.g. 802.1x)? If this is your question, my answer is no. But I'm not sure this is your question! =20 I get the feeling we are stumbling over terminology again here. Please clarify. Thanks Sue =20 I won't want to upset the apple cart, so no objections for it going to BOF as is. But for the WG - perhaps we should reconsider. =20 Regarding the dates - I see Mauricio's point, but again - there's less of a problem completing before the specified date than dragging past it. Let's keep the milestones as they are. =20 =20 ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Tuesday, January 31, 2006 12:33 PM To: Sanchez, Mauricio (PNB Roseville); nea@ietf.org Cc: Steve Hanna Subject: RE: [Nea] Draft NEA WG charter: Please review =09 =09 Thanks for the quick turnaround. Inline ... ________________________________ From: Sanchez, Mauricio (PNB Roseville) [mailto:mauricio.sanchez@hp.com]=20 Sent: Tuesday, January 31, 2006 11:08 AM To: Susan Thomson (sethomso); nea@ietf.org Cc: Steve Hanna Subject: RE: [Nea] Draft NEA WG charter: Please review =09 =09 =20 Good beginning... =20 Couple comments/questions: =20 -How do protocols #2 and #3 differ if both are called out as being IF-PT. May lead to confusion. We may want to consider just calling out IF-PT once and placing various requirements that the single protocol must meet rather than breaking them out to seem like they're two protocols.=20 =09 [Susan] Yes, the fact that this may lead to confusion crossed my mind as well. The current definition of IF-PT in problem statement I-D is quite general, the intent being (I believe) to cover a broad range of underlying technologies.=20 =20 But in the case of the EAP infrastructure (which is the scope we are talking about here), it covers a number of different protocol layers: EAP method e.g. some EAP tunneling method, EAP protocol itself, and EAP transport e.g. 802.1x, some flavor of EAP over IP. These are all separable protocols, addressed in various working groups both inside and outside the IETF. So we do need to separate out the protocols and their requirements. However, we may want to re-think the naming scheme. =20 I would propose that we leave this as is for the initial BOF request on Friday so that it is consistent with the naming used in -00 version of the problem-statement I-D. We can revisit this in the -01 version and then update the charter to match. =20 =20 -What is the rationale behind the selected milestone dates? In other words, why did you pick those dates and not others (perhaps by being more aggressive and pulling them in)? =09 [Susan] There is always a tension between being aggressive and being realistic! I think this WG may be somewhat more challenging than normal given its broad scope and the need for cross-area, cross-WG collaboration. As it stands, the milestones only give us 2 IETF meetings to wrap up all the requirements in the intial scope assuming this BOF is successful in March. If we can complete before then, great. But I would not bank on it. =20 - Why would December 2006's milestone not be done in conjunction with the prior two milestones? Waiting until 12/2006 to get the ball rolling on protocols seems like a long wait.=20 =09 [Susan] So the intent was not that we need to wait till then for any protocol work to proceed, but rather this is an official checkpoint with ADs of where we think we are in terms of doing any necessary re-chartering or other planning based on the requirements specified. In fact, there is some protocol work already underway e.g. Radius attribute definition in Radext WG, and the start of standardizing EAP methods in the EMU WG. The NEA WG would indeed need to be reviewing related work in other WGs while the requirements are being drawn up, to provide any heads-up and course corrections as soon as possible. =20 Hope this makes sense. Thanks Susan =20 Cheers, MS ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson (sethomso) Sent: Tuesday, January 31, 2006 7:26 AM To: nea@ietf.org Cc: Steve Hanna Subject: [Nea] Draft NEA WG charter: Please review =09 =09 Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. =20 The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). =20 The scope of the initial charter is on the following protocols that support architectures for network endpoint assessment (as described in draft-thomson-nea-problem-statement-00.txt): =20 1. IF-PB (posture broker protocol) 2. IF-PT (EAP method suitable for carrying posture information as well as supporting authentication) 3. IF-PT (EAP over IP transport protocol) 4. IF-NAE (Radius attributes for network access enforcement) =20 Other interfaces that may be included in the charter at a later date include: --- IF-PA (posture attribute protocol) --- IF-SB (Protocol between server broker and posture server. Name of interface TBD in problem-statement I-D. ) =20 =09 Note that the initial scope of the WG targets architectures that use the EAP/Radius framework for IF-PT (posture transport interface) and IF-NAE (network access enforcement interface). This does not preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the initial charter. =20 Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs to identify the appropriate WG for meeting these requirements. =20 Milestones: =20 June 2006: * Submit requirements I-D to IETF including=20 --- requirements for IF-PT (EAP method layer)=20 --- requirements for IF-NAE=20 =20 September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over TLS) --- requirements for IF-PB =20 December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. =20 Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB * Submit I-D on protocols to be defined in this WG e.g. IF-PB specification ------_=_NextPart_001_01C626B8.AE5B7315 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 

From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Blumenthal,=20 Uri
Sent: Tuesday, January 31, 2006 1:55 PM
To:=20 nea@ietf.org
Subject: RE: [Nea] Draft NEA WG charter: Please = review

Sue,  do you expect that the protocol (IF-PT) = would be=20 different depending on what carrier it's traveling=20 over?
[Susan] 
When = you say=20 IF-PT do you mean the EAP method layer (e.g. an EAP tunneling = method),=20 versus the EAP underlying transport (e.g. 802.1x)? If this is = your=20 question, my answer is no. But I'm not sure this is your=20 question!
 
I get the feeling we are = stumbling over=20 terminology again here. Please = clarify.
Thanks
Sue
 
I won't=20 want to upset the apple cart, so no objections for it going to BOF as = is. But=20 for the WG - perhaps we should = reconsider.
 
Regarding=20 the dates - I see Mauricio's point, but again - there's less = of a=20 problem completing before the specified date than dragging past = it. Let's=20 keep the milestones as they are.
 
 
From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson=20 (sethomso)
Sent: Tuesday, January 31, 2006 12:33 = PM
To:=20 Sanchez, Mauricio (PNB Roseville); nea@ietf.org
Cc: Steve=20 Hanna
Subject: RE: [Nea] Draft NEA WG charter: Please=20 review

Thanks for the quick turnaround. Inline=20 ...

From: Sanchez, Mauricio (PNB = Roseville)=20 [mailto:mauricio.sanchez@hp.com]
Sent: Tuesday, January = 31,=20 2006 11:08 AM
To: Susan Thomson (sethomso);=20 nea@ietf.org
Cc: Steve Hanna
Subject: RE: = [Nea] Draft=20 NEA WG charter: Please review

 
Good beginning...
 
Couple = comments/questions:
 
-How do = protocols #2 and=20 #3 differ if both are called out as being IF-PT.  May lead to = confusion.  We may want to consider just calling out IF-PT = once and=20 placing various requirements that the single protocol must meet = rather=20 than breaking them out to seem like they're two protocols. =
[Susan] Yes, the=20 fact that this may lead to confusion crossed my mind as well. = The=20 current definition of IF-PT in problem statement I-D is quite = general, the=20 intent being (I believe) to cover a broad range of underlying=20 technologies.
 
But in the = case of the=20 EAP infrastructure (which is the scope we are talking about here), = it=20 covers a number of different protocol layers: EAP method e.g. some = EAP=20 tunneling method, EAP protocol itself, and EAP transport e.g. = 802.1x, some=20 flavor of EAP over IP. These are all separable protocols, = addressed in=20 various working groups both inside and outside the IETF. So we do = need to=20 separate out the protocols  and their requirements. = However, we=20 may want to re-think the naming=20 scheme.
 
I would = propose that we=20 leave this as is for the initial BOF request on Friday so that it = is=20 consistent with the naming used  in -00 version of the=20 problem-statement I-D. We can revisit this in the -01 version and = then=20 update the charter to match.
 
 
-What is the = rationale behind=20 the selected milestone dates? In other words, why did you pick = those dates=20 and not others (perhaps by being more aggressive and pulling them=20 in)?
[Susan]  There=20 is always a tension between being aggressive and = being realistic! I=20 think this WG may be somewhat more challenging than normal = given its=20 broad scope and the need for cross-area, cross-WG collaboration. = As it=20 stands, the milestones only give us 2 IETF meetings to wrap up all = the=20 requirements in the intial scope assuming this BOF is successful = in March.=20 If we can complete before then, great. But I would not bank on=20 it.
 
- Why would = December 2006's=20 milestone not be done in conjunction with the prior two = milestones? =20 Waiting until 12/2006 to get the ball rolling on protocols seems = like a=20 long wait.
[Susan]  So the intent was not that we = need to=20 wait till then for any protocol work to proceed, but rather this = is an=20 official checkpoint with ADs of where we think we are in terms of = doing=20 any necessary re-chartering or other planning based on the = requirements=20 specified. In fact, there is some protocol work already underway = e.g.=20 Radius attribute definition in Radext WG, and the start of = standardizing=20 EAP methods in the EMU WG. The NEA WG would indeed need to be = reviewing=20 related work in other WGs while the requirements are being drawn = up, to=20 provide any heads-up and course corrections as soon as=20 possible.
 
Hope this=20 makes sense.
Thanks
Susan
 
Cheers,
MS

From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson=20 (sethomso)
Sent: Tuesday, January 31, 2006 7:26=20 AM
To: nea@ietf.org
Cc: Steve=20 Hanna
Subject: [Nea] Draft NEA WG charter: Please=20 review

Architectures have been implemented = in the=20 industry to assess the software or hardware = configuration of=20 endpoint devices for the purposes of monitoring or enforcing = compliance=20 of endpoints to an organization's policy for access to the = network.=20 These architectures are not fully interoperable since some = of the=20 protocols used to implement the architecture are not=20 standards.
 
The first=20 purpose of the proposed working group is to define requirements = for the=20 protocols needed to ensure interoperability in an NEA system. = The second=20 purpose of the working group is to ensure standardization of = protocols=20 that meet these requirements. = In=20 some cases, these protocols may best be standardized in another = working=20 group. Therefore, the proposed working group will work with the = area=20 directors to determine the best way to complete this = standardization=20 effort (in the proposed working group or in another=20 one).
 
The=20 scope of the initial charter is on the following protocols that support=20 architectures for network endpoint assessment (as described in=20 = draft-thomson-nea-problem-statement-00.txt):<= /SPAN>
 
1. IF-PB=20 (posture broker protocol)
2. IF-PT=20 (EAP method suitable for=20 carrying posture information as=20 well as supporting authentication)
3. IF-PT=20 (EAP over IP transport=20 protocol)
4. IF-NAE=20 (Radius attributes for network access = enforcement)
 
Other=20 interfaces  that may be included in the charter at a later = date=20 include:
--- IF-PA (posture = attribute protocol)
--- IF-SB (Protocol between server broker = and=20 posture server. Name of = interface=20 TBD in problem-statement=20 I-D. )
 
Note=20 that the initial scope of the WG targets architectures that use = the=20 EAP/Radius framework for IF-PT (posture transport interface) and = IF-NAE=20 (network access enforcement interface). This does not=20 preclude the = standardization=20 of other posture transport=20 protocols or network authorization protocols in the = future, but=20 this is not part of the initial=20 charter.
 
Work will be=20 carried out in two phases. In the first phase, the WG will define = requirements for=20 each of the protocols=20 identified in 1) - 4) above. When the requirements have = been=20 defined, this WG will work = with the=20 responsible ADs to identify the appropriate = WG for meeting these=20 requirements.
 
Milestones:
 
June 2006:
* Submit=20 requirements I-D to IETF =  including 
--- requirements for IF-PT (EAP = method layer) =
--- requirements for IF-NAE =
 
September=20 2006:
* Submit=20 revised requirements I-D to IETF that includes above=20 plus:
---=20 requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP = over=20 TLS)
---=20 requirements for IF-PB
 
December=20 2006:
* Review=20 ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) = and work=20 with ADs to identify the WG responsible for accommodating = protocol=20 requirements that are not currently being = met.
 
Feb=20 2007:
*=20 Submit  requirements I-D to IESG for publication as Info=20 RFC
* Revise WG=20 charter to accommodate definition of protocols not covered = in other WGs e.g. = IF-PB
* Submit I-D=20 on  protocols to be defined in this WG e.g. IF-PB=20 = specification
------_=_NextPart_001_01C626B8.AE5B7315-- --===============1963176324== 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 --===============1963176324==--