From nea-bounces@ietf.org Tue Sep 2 12:42:45 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6223A6AF9; Tue, 2 Sep 2008 12:42:45 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B902A28C111 for ; Tue, 2 Sep 2008 12:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.158 X-Spam-Level: X-Spam-Status: No, score=-5.158 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hDEgh7qtOJW for ; Tue, 2 Sep 2008 12:42:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7DD2C3A6AE5 for ; Tue, 2 Sep 2008 12:42:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,317,1217808000"; d="scan'208,217";a="71940306" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 02 Sep 2008 19:42:46 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m82Jgier023299; Tue, 2 Sep 2008 12:42:44 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m82Jgc8t009156; Tue, 2 Sep 2008 19:42:44 GMT Received: from xmb-rtp-209.amer.cisco.com ([64.102.31.11]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Sep 2008 15:42:44 -0400 Received: from 10.98.29.185 ([10.98.29.185]) by xmb-rtp-209.amer.cisco.com ([64.102.31.11]) with Microsoft Exchange Server HTTP-DAV ; Tue, 2 Sep 2008 19:42:43 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Tue, 02 Sep 2008 15:42:40 -0400 From: Brian Ford To: Message-ID: Thread-Topic: Request for new Attributes and Component Types (subtypes) for PA Thread-Index: AckNNA8g6bcNC9hY+U6APs7ntBqjGQ== Mime-version: 1.0 X-OriginalArrivalTime: 02 Sep 2008 19:42:44.0284 (UTC) FILETIME=[11ADE7C0:01C90D34] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5124; t=1220384564; x=1221248564; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=brford@cisco.com; z=From:=20Brian=20Ford=20 |Subject:=20re=3A=20Request=20for=20new=20Attributes=20and= 20Component=20Types=20(subtypes)=20for=20PA |Sender:=20; bh=zbEzN04IZjhsI+Xc5qrS5MEKGEt2HWHMnzipI/UP0/8=; b=T1eepEUl6fLBV5apBAcaqojkZ99UbmU6LtJoBLIh5OCWIm55B7RZ8YAO+I cDdw+S+oZHU2JKe0v+HFOpEIrkMlgtXEJyshWSCxeZ1uoGmFMjkm6CD+K7KR QQ0EZCHYZb; Authentication-Results: sj-dkim-3; header.From=brford@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: NEA Subject: Re: [Nea] Request for new Attributes and Component Types (subtypes) for PA X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1663929338==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1663929338== Content-type: multipart/alternative; boundary="B_3303214961_1623905" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3303214961_1623905 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Paul, Please note that the link to the slides in the message below doesn=B9t work. The IETF 72 NEA slides seem to be in the same directory in a file titled =B3nea-1.ppt=B2. Given that the members of the working group didn=B9t have access to these slides I would request that your =B3end of August=B2 request date be extended b= y at least 30 days. Liberty, Brian > Date: Fri, 8 Aug 2008 15:27:09 -0700 > From: "Paul Sangster" > Subject: [Nea] Request for new Attributes and Component Types > (subtypes) for PA > To: > Message-ID: > =20 > om> > =20 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > As discussed in Dublin, we have a tight schedule for the PA and PB specs > prior to WGLC, so need to make major progress right away on all major > open topics for the specifications. The primary open question for PA is > to complete the standard attribute name space and list of component > types (subtypes) for the 1.0 spec. The editors are currently working on > additional attribute proposals, but we would like to hear from the WG. > =20 > At the start of open mic in Dublin, we presented 2 slides (32 and 33) > listing the currently defined attributes and components and requested > feedback from the WG (see slides at > www3.ietf.org/proceedings/08jul/slides/nea-0.ppt). The editors would > like to request a final call for new attributes and components types for > PA by 5PM PDT on Aug 22nd. Proposals should describe the need and use > of the new attribute (or component type) and any associated information > required. This will enable us to get another revision out by the end of > August and stay on schedule. > =20 > Thanks, > =20 > Paul and Kaushik > PA Editors > =20 --B_3303214961_1623905 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable re: Request for new Attributes and Component Types (subtypes) for PA= Paul,

Please note that the link to the slides in the message below doesn’t = work.  The IETF 72 NEA slides seem to be in the same directory in a fil= e titled “nea-1.ppt”.

Given that the members of the working group didn’t have access to the= se slides I would request that your “end of August” request date= be extended by at least 30 days.

Liberty,

Brian



Date: Fri, 8 Aug 2008 15:27:09 -0700<= BR> From: "Paul Sangster" <Paul_Sangster@symantec.com>
Subject: [Nea] Request for new Attributes and Component Types
    (subtypes) for    PA
To: <nea@ietf.org>
Message-ID:
    <AB96CED6= 33A7C246BDC661DBEE1CF01F04654621@TUS1XCHCLUPIN12.enterprise.veritas.com<= /U>>
    
Content-Type: text/plain; charset=3D"us-ascii"

As discussed in Dublin, we have a tight schedule for the PA and PB specs prior to WGLC, so need to make major progress right away on all major
open topics for the specifications.  The primary open question for PA = is
to complete the standard attribute name space and list of component
types (subtypes) for the 1.0 spec.  The editors are currently working = on
additional attribute proposals, but we would like to hear from the WG.
 
At the start of open mic in Dublin, we presented 2 slides (32 and 33)
listing the currently defined attributes and components and requested
feedback from the WG (see slides at
www3.ietf.org/proceedings/08jul/slides/nea-0.ppt).  The editors would<= BR> like to request a final call for new attributes and components types for PA by 5PM PDT on Aug 22nd.  Proposals should describe the need and use=
of the new attribute (or component type) and any associated information
required.  This will enable us to get another revision out by the end = of
August and stay on schedule.
 
Thanks,
 
Paul and Kaushik
PA Editors
 
--B_3303214961_1623905-- --===============1663929338== 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://www.ietf.org/mailman/listinfo/nea --===============1663929338==-- From nea-bounces@ietf.org Tue Sep 2 13:24:32 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4001228C16F; Tue, 2 Sep 2008 13:24:32 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954C628C160 for ; Tue, 2 Sep 2008 13:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7sjqC-HGMsf for ; Tue, 2 Sep 2008 13:24:24 -0700 (PDT) Received: from extu-mxob-2.symantec.com (extu-mxob-2.symantec.com [216.10.194.135]) by core3.amsl.com (Postfix) with ESMTP id 84A0428C171 for ; Tue, 2 Sep 2008 13:24:24 -0700 (PDT) Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by extu-mxob-2.symantec.com (8.14.1/8.14.1) with ESMTP id m82KOSZF019084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 13:24:28 -0700 Received: from reserved-155-64-230-19.ges.symantec.com ([155.64.230.19] helo=TUS1XCHECNPIN02.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1KacQO-0004ah-7Y; Tue, 02 Sep 2008 13:24:28 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN02.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Sep 2008 13:24:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Sep 2008 13:23:26 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for new Attributes and Component Types (subtypes) for PA Thread-Index: AckNNA8g6bcNC9hY+U6APs7ntBqjGQABM8hw References: From: "Paul Sangster" To: "Brian Ford" X-OriginalArrivalTime: 02 Sep 2008 20:24:28.0123 (UTC) FILETIME=[E6156AB0:01C90D39] Cc: NEA Subject: Re: [Nea] Request for new Attributes and Component Types (subtypes) for PA X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0029830381==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0029830381== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C90D39.C274ACDE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C90D39.C274ACDE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Unfortunately it looks like someone at the IETF moved the file to nea-1.ppt probably during the conversion of the presentations to html. Here is the current HTML link in case anyone didn't see it prior to the change: =20 http://www.ietf.org/proceedings/08jul/slides/nea-0/nea-0.htm =20 The editors are on a pretty tight schedule to hit the milestones discussed during the meeting so we'd need to discuss whether to have another comment period. We are interested in seeing this thread finish out so we can assess how much can make it into the next draft (due this month). We'll follow up in a bit on your request. =20 Paul ________________________________ From: Brian Ford [mailto:brford@cisco.com]=20 Sent: Tuesday, September 02, 2008 12:43 PM To: Paul Sangster Cc: NEA; Kaushik Narayan Subject: re: Request for new Attributes and Component Types (subtypes) for PA =09 =09 Paul, =09 Please note that the link to the slides in the message below doesn't work. The IETF 72 NEA slides seem to be in the same directory in a file titled "nea-1.ppt". =09 Given that the members of the working group didn't have access to these slides I would request that your "end of August" request date be extended by at least 30 days. =09 Liberty, =09 Brian =09 =09 =09 =09 Date: Fri, 8 Aug 2008 15:27:09 -0700 From: "Paul Sangster" Subject: [Nea] Request for new Attributes and Component Types (subtypes) for PA To: Message-ID: =09 =20 Content-Type: text/plain; charset=3D"us-ascii" =09 As discussed in Dublin, we have a tight schedule for the PA and PB specs prior to WGLC, so need to make major progress right away on all major open topics for the specifications. The primary open question for PA is to complete the standard attribute name space and list of component types (subtypes) for the 1.0 spec. The editors are currently working on additional attribute proposals, but we would like to hear from the WG. =20 At the start of open mic in Dublin, we presented 2 slides (32 and 33) listing the currently defined attributes and components and requested feedback from the WG (see slides at www3.ietf.org/proceedings/08jul/slides/nea-0.ppt). The editors would like to request a final call for new attributes and components types for PA by 5PM PDT on Aug 22nd. Proposals should describe the need and use of the new attribute (or component type) and any associated information required. This will enable us to get another revision out by the end of August and stay on schedule. =20 Thanks, =20 Paul and Kaushik PA Editors =20 ------_=_NextPart_001_01C90D39.C274ACDE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable re: Request for new Attributes and Component Types = (subtypes) for PA
Unfortunately it looks like someone at the IETF = moved the=20 file to nea-1.ppt probably during the conversion of the presentations to = html.  Here is the current HTML link in case anyone didn't see it = prior to=20 the change:
 
htt= p://www.ietf.org/proceedings/08jul/slides/nea-0/nea-0.htm
 
The editors are on a pretty tight schedule to = hit the=20 milestones discussed during the meeting so we'd need to discuss whether = to have=20 another comment period.  We are interested in seeing this thread = finish out=20 so we can assess how much can make it into the next draft (due this = month).  We'll follow up in a bit on your = request.
 
Paul

From: Brian Ford = [mailto:brford@cisco.com]=20
Sent: Tuesday, September 02, 2008 12:43 PM
To: = Paul=20 Sangster
Cc: NEA; Kaushik Narayan
Subject: re: = Request for=20 new Attributes and Component Types (subtypes) for = PA

Paul,

Please note that the link to = the slides=20 in the message below doesn’t work.  The IETF 72 NEA slides = seem to be in=20 the same directory in a file titled = “nea-1.ppt”.

Given that the members=20 of the working group didn’t have access to these slides I would = request that=20 your “end of August” request date be extended by at least = 30=20 days.

Liberty,

Brian
Date: Fri, 8 Aug 2008 15:27:09 = -0700
From: "Paul=20 Sangster" <Paul_Sangster@symantec.com>
Subject:=20 [Nea] Request for new Attributes and Component=20 Types
    (subtypes) for =    PA
To:=20 <nea@ietf.org>
Message-ID:
&= nbsp;   <AB96CED633A7C246BDC661DBEE1CF01F04654621@TUS1XCHCLUPIN12.= enterprise.veritas.com>
    
= Content-Type:=20 text/plain; charset=3D"us-ascii"

As discussed in Dublin, we = have a=20 tight schedule for the PA and PB specs
prior to WGLC, so need to = make=20 major progress right away on all major
open topics for the=20 specifications.  The primary open question for PA is
to = complete the=20 standard attribute name space and list of component
types = (subtypes) for=20 the 1.0 spec.  The editors are currently working = on
additional=20 attribute proposals, but we would like to hear from the = WG.
 
At=20 the start of open mic in Dublin, we presented 2 slides (32 and=20 33)
listing the currently defined attributes and components and=20 requested
feedback from the WG (see slides=20 at
www3.ietf.org/proceedings/08jul/slides/nea-0.ppt).  The = editors=20 would
like to request a final call for new attributes and = components=20 types for
PA by 5PM PDT on Aug 22nd.  Proposals should = describe the=20 need and use
of the new attribute (or component type) and any = associated=20 information
required.  This will enable us to get another = revision=20 out by the end of
August and stay on=20 schedule.
 
Thanks,
 
Paul and Kaushik
PA=20 = Editors
 
------_=_NextPart_001_01C90D39.C274ACDE-- --===============0029830381== 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://www.ietf.org/mailman/listinfo/nea --===============0029830381==-- From nea-bounces@ietf.org Tue Sep 2 22:20:31 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0728E3A6BFB; Tue, 2 Sep 2008 22:20:31 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A706D3A6BFB for ; Tue, 2 Sep 2008 22:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_50=0.001, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiHX8qIrt3OW for ; Tue, 2 Sep 2008 22:20:27 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by core3.amsl.com (Postfix) with ESMTP id B5DAE3A6BFA for ; Tue, 2 Sep 2008 22:20:26 -0700 (PDT) Received: from mail.networksolutionsemail.com (ns-omr10 [10.49.6.73]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m835KRkc020055 for ; Wed, 3 Sep 2008 01:20:29 -0400 Received: (qmail 19397 invoked by uid 78); 3 Sep 2008 05:20:26 -0000 Received: from unknown (HELO ?10.0.1.97?) (75.82.30.208) by ns-omr10.lb.hosting.dc2.netsol.com with SMTP; 3 Sep 2008 05:20:26 -0000 Message-Id: From: Randy Turner To: Brian Ford In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 2 Sep 2008 22:20:25 -0700 References: X-Mailer: Apple Mail (2.928.1) Cc: NEA Subject: Re: [Nea] IETF NEA PA Categories and Attributes [Was Re: Nea Digest, Vol 34, Issue 5] X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Hi Brian, After thinking about the comparison between SNMP and NEA, there are similarities when it comes to a management entity desiring to know the state of another device on the network, but the similarities pretty much end there, so I agree that SNMP and NEA are not quite the same thing. They share the common property of potentially having multiple "assessment methods" per your terminology. I would like to characterize one of the differences between NEA and SNMP, and that is, the frequency of state change. Over the years, SNMP has evolved to better handle dynamic, and potentially high frequency, state changes so that management stations can reflect the most up-to- date status possible. I think the problem that NEA is trying to solve, whereby we're trying to assess the "posture" of a device, is different in that the "frequency" of posture change is much lower. SNMP has evolved to deal with potentially high-frequency state changes in the device, wherein I am of the opinion that "postures" don't change that often, or at least that's my expectation. If the security posture of a device (a posture that can be remediated) is changing at a high frequency, and you require the services of a posture monitoring/posture remediation service to deal with this, then I would say that there is a much larger site administrative problem that needs to be dealt with. A problem that is probably out of scope for NEA. And if this "low frequency posture change" assumption is correct, we shouldn't be erecting possibly multiple complex assessment methods that have varying degrees of quality or timeliness. It seems like we could just "standardize" on an event driven mechanism that automatically notifies some "management entity in the sky" that a posture change has occurred. Like SNMP traps/informs, this technique would scale better as the topology grows very large, but requires that posture changes be an infrequent event so that chatter is minimized. With notifications, there's no traffic unless some posture is changing somewhere. The notification could indicate "what" changed so as to possibly make remediation quicker. To summarize this email, I guess I'm proposing that a property of a "posture" is that it doesn't change that often; i.e., the frequency of posture change is low. As opposed to the types of potentially "high frequency" status events that exist in certain MIBs that SNMP must manage. Randy On Aug 29, 2008, at 3:51 PM, Brian Ford wrote: > Randy, > > Inline. > > On 8/29/08 4:13 PM, "Randy Turner" wrote: > >> >> Hi Brian, >> >> Thanks for the note. >> >> I do agree that a management entity may obtain attributes from a >> device using any number of "assessment methods", but it seems to me >> that the management entity would only "maintain" one copy of the data >> set that was obtained (however the attributes were collected). >> >> Each time the management entity acquires attributes (whichever >> assessment method is used), it would just overwrite the previous >> collected >> attributes for the particular MAC address. > > You can do it that way but Id assert that the solution winds up losing > access to some really valuable data. Namely, what changed. Having > implemented our flavors a few times for a few different folks I can > tell you > "what changed" becomes important. > >> >> SNMP management stations (in theory) have the same problem - they >> could issue a "get" for device status information, or optionally, >> receive >> a trap with status updates, or more reliably, an "inform" message >> with >> status updates. Devices could implement their SNMP agents with >> similar assessment methods as you suggest, including more distributed >> forms of acquisition such as agent-x. However, in the management >> stations implementations I'm aware of, it's not clear to me that keep >> a separate copy of the data depending upon the "status assessment >> method" >> used in the device. > > OK. I agree with your SNMP description. Using that solution your PDP > actions are based on state where all the variables that comprise > that state > are hopefully all taken at approximately the same time. State = a > snapshot > in time. In my opinion that's what SNMP was designed to do well. > > You can look at this (NEA) as being the same problem (as SNMP). I > don't. > NEA solutions offer the capability to programmatically change how an > endpoint accesses and transmits data across a network based on > information > received from the endpoint and various devices in the network about > the > endpoint over time. > > In my mind SNMP is like solving a computer science "train track" > switching > problem where one student looks out over the trains and the tracks. > NEA is > like solving the same problem in a darkened room with students > spread around > the track. Some have small lights. Others can only hear the > train. Still > others have their fingers on the track. But there is only one > person who > controls all the switches. > >> >> My interpretation of your text seems to suggest that there are both >> "qualitative" and "trust" implications that are associated with >> assessment >> methods, and that you believe that the management entity should be >> aware of both of these aspects of the attributes it receives from a >> device. >> Is this correct? > > Good question. I'm not sure. I do think we need to look at > multiple data > sources and multiple snapshots of time (i.e. Not over write the > previous > data). > > Think about this. How do you envision handling the problem where an > endpoint changes state? Do you intend to act on that after you > discover it > because you queried the endpoint? Will your endpoint be capable of > signaling a state change? If an endpoint suddenly signals a state > change > would you want the capability of having one action or multiple > possible > actions? > >> >> Let me know if I've misread or misinterpreted your previous text. > Sure. >> >> Thanks again, >> Randy > Liberty, > > Brian >> >> >> >> On Aug 29, 2008, at 9:14 AM, Brian Ford wrote: >> >>> >>> Randy, >>> >>> I thought that some of the attributes you proposed would be vary >>> useful if >>> we could explain the context from which they were derived. I >>> defined that >>> sort of context in my previous message to the list. >>> >>> For example: if I'm writing rules for a PDP and I can: >>> >>> 1- Assume that I have data from an endpoint, AND >>> 2- Assume the data was the result of a query to the endpoint AND >>> 3- the data says that the device can forward bits (i.e. Route) >>> >>> That would make for an interesting rule about how I might apply >>> policy to >>> that device (which is now a router and not an endpoint). >>> >>> It would be perhaps even more interesting if I had probed (scanned) >>> that >>> device and the result of the probe says that it something else that >>> should >>> not be able to route. >>> >>> Liberty, >>> >>> Brian >>> >>> >>> On 8/27/08 3:00 PM, "nea-request@ietf.org" >>> wrote: >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Tue, 26 Aug 2008 14:12:14 -0700 >>>> From: Randy Turner >>>> Subject: Re: [Nea] proposals for attribute categories and >>>> attributes, >>>> etc. >>>> To: Stephen Hanna >>>> Cc: nea@ietf.org, Paul Sangster >>>> Message-ID: <4A6D7DA5-193A-4FF4- >>>> AA3B-70E0304A1025@amalfisystems.com> >>>> Content-Type: text/plain; charset=US-ASCII; format=flowed; >>>> delsp=yes >>>> >>>> Hi Steve, >>>> >>>> Thanks for the note. >>>> >>>> I'll try and address your comments one at a time, using your >>>> labels. >>>> >>>> Forwarding Enabled >>>> ---------------------------- >>>> From the perspective of embedded devices, the application set is >>>> more >>>> or less >>>> "locked down" so you know that, if "something" can forward, you >>>> know >>>> exactly >>>> the circumstances under which it does forward "bits". If you have >>>> an >>>> architecture >>>> that allows arbitrary apps to be added, then I agree, you're never >>>> quite sure what's >>>> going on. This situation might call for an attribute that >>>> indicates >>>> whether or not the >>>> application set can be modified by some entity other than the >>>> manufacturer. If the >>>> device can be updated with arbitrary apps, then a forwarding >>>> attribute >>>> may not >>>> make sense. But if the device has a "locked down" application >>>> environment, and there is >>>> an attribute that can allow forwarding by the firmware, then maybe >>>> this would make >>>> more sense. I'm open to discussing this further.... >>>> >>>> Secure Time Enabled >>>> ----------------------------- >>>> The idea here is that we wanted to make sure that if a device was >>>> acquiring it's notion >>>> of time from "some source", that the source be trusted as a secure >>>> source, and that the >>>> manner in which the time is acquired cannot be tampered with >>>> enroute >>>> from the source >>>> to the device. As you suggest, we wanted to protect the use of >>>> certificate checking (yes, >>>> many high-end multifunction peripherals have cert mgmt capability), >>>> and any other >>>> functionality that requires accurate time, I had a feeling that the >>>> use of "secure" might be >>>> interpreted any number of ways. I think it's more important that if >>>> it's possible to >>>> configure a device to use a time acquisition method that is NOT >>>> secure, or a time source >>>> that is not "approved" by the site, then this type of attribute >>>> would >>>> be a part of the device >>>> "posture". I'll try and come up with another way to indicate this >>>> basic 2-part requirement. >>>> I think "time source" might be one attribute (which was part of the >>>> proposal), and then, if the device >>>> is capable of being configured with a protocol that does not >>>> protect >>>> the integrity of the >>>> time acquired from a trusted source, then we need a way to prevent >>>> this from happening (if >>>> this is a site requirement). >>>> >>>> I'll mull over your suggestion about NOT delaying the base NEA >>>> specs, >>>> and deferring this >>>> information to another document, but the solution may be so concise >>>> as >>>> to essentially produce >>>> a 1-page draft :) If we can come up with something concise (in a >>>> timeframe that doesn't >>>> delay the NEA schedule) then it would be nice to spec it....if we >>>> can't then I agree we would >>>> have to address it in some later spec. >>>> >>>> Configuration State >>>> -------------------------- >>>> You are correct, this type of value may consist of attributes that >>>> are >>>> not necessarily, but then again >>>> they may be security related - only the vendor would know for sure. >>>> It could be that this hash >>>> is a hash over security attributes that (for whatever reason) >>>> aren't >>>> standardized or haven't been >>>> spec'd in any way. This value allows for vendors (or potentially >>>> site >>>> admins) to define their own >>>> set of posture attributes without having to worry about >>>> standardization or registries, etc. >>>> >>>> You'll hear me say this more than once, but the concern is that >>>> we're >>>> defining a protocol that >>>> allows administrators to determine if a device configuration is >>>> conformant to some local security >>>> policy. And I'm assuming that, if this WG doesn't do it, that some >>>> future standards entity will >>>> define a way to remediate a situation where one or more devices are >>>> not conformant. >>>> >>>> This is a very nice and convenient system that I think would be of >>>> high value to administrators. >>>> And even though we've used the word "security" in the charter >>>> (and in >>>> your email), this protocol >>>> could actually work with any type of device attributes. In the >>>> future, >>>> if a site decides to deploy a >>>> posture monitoring and remediation system that monitors and >>>> remediates >>>> the "security" attributes, it >>>> seems likely that someone might want to use the same infrastructure >>>> for other types of attributes >>>> as well. I know I'm breaching on stuff that's out of scope and >>>> not a >>>> part of the charter, but it seems >>>> logical that once we have a complete monitoring/remediation system, >>>> someone's going to ask >>>> the question about "configuration" management. At least that's my >>>> assumption. >>>> >>>> In lieu of any other "system" that does monitoring/remediation, the >>>> "configuration state" attribute >>>> would allow custom postures to be defined that could consist of >>>> vendor- >>>> specific security attributes, >>>> non-security-related attributes, or a mix, and still use (at least) >>>> the posture monitoring and reporting >>>> capabilities that would be possible with our initial NEA work. >>>> >>>> PSTN_Fax_Enabled >>>> --------------------------------- >>>> Some hardcopy device vendors would consider this a security >>>> attribute, >>>> in that the device-local FAX >>>> capability could allow an unauthorized party access to device >>>> resources (or to exhaust device >>>> resources) in some manner. >>>> >>>> This would not be what I would call a "Generic" attribute >>>> applicable >>>> to all devices, but instead only >>>> relegated to hardcopy devices. >>>> >>>> Admin_PW_Enabled >>>> ----------------------------- >>>> I agree about the name of this attribute - we could use something >>>> like >>>> "Factory-default-PW-Enabled" >>>> or some equivalent. Even though I considered this a hardcopy issue, >>>> it's not something that a >>>> Linux, Windows, or Mac OS X admin would run into, since those >>>> installation processes require the >>>> installer (local or remote) to define root or admin credentials as >>>> well as their associated passwords. >>>> However, to your point, it could apply to other types of network >>>> devices as well. And to reiterate, I >>>> agree that a different name could be used. >>>> >>>> >>>> SMI Subtrees >>>> ------------------ >>>> I may have worded it incorrectly, but I think you have summarized >>>> the >>>> concern that we were thinking >>>> about. >>>> >>>> Software Modules >>>> ------------------------ >>>> Let me go back and review the source of this particular issue. I'll >>>> get back to you (and the list). >>>> >>>> >>>> Thanks again for the comments! More are welcome! >>>> >>>> Randy >>>> >>>> >>>> >>>> On Aug 26, 2008, at 11:44 AM, Stephen Hanna wrote: >>>> >>>>> Randy, >>>>> >>>>> Thanks for sending your comments. I found them quite interesting! >>>>> I'm sorry that it has taken me a few days to respond. I was on >>>>> holiday for a few days last week. >>>>> >>>>> Let me address your suggestions individually. Note that these >>>>> are my personal comments and I'm sending them as an individual >>>>> not as a WG chair. Please consider them in that context. >>>>> >>>>> Forwarding Enabled: I like the idea but forwarding can happen >>>>> at the application layer, which is almost impossible to detect. >>>>> Of course, this might not be an issue for an embedded device. >>>>> Maybe three values are called for: Forwarding Enabled (known >>>>> to be happening), Forwarding Possible (could be happening but >>>>> not sure), and Forwarding Disabled (strongly believed that >>>>> no forwarding is happening, as when there's no application >>>>> software and the operating software does not forward). >>>>> >>>>> Secure Time Enabled: Having a good source of time is important >>>>> for many security protocols (for checking expiration dates on >>>>> certificates, for example). However, this attribute does raise >>>>> a question: what is the definition of "secure" here? >>>>> Is it secure to use an onboard source of time? Probably. >>>>> What about SNTP or NTP? Probably not, unless you use some >>>>> form of authentication. Are the authentication techniques >>>>> described in RFC 1305 (NTPv3) enough? Maybe not, since they >>>>> are based on DES and MD5. SNTPv4 (RFC 4330) doesn't specify >>>>> a security algorithm. You could use the system described in >>>>> draft-ietf-ntp-autokey-04.txt but that's just an Internet Draft. >>>>> And which algorithms and identity schemes from that spec >>>>> are being used? Are those still secure? And, as you say, >>>>> Time Source must also be considered. Using a secure time >>>>> protocol to fetch time from an untrustworthy time source >>>>> isn't really secure. >>>>> >>>>> Instead of leaving all the decisions to the NEA Client and >>>>> having the client indicate "Secure Time Enabled" to the >>>>> NEA Server, it would be more consistent with the rest of >>>>> NEA if we defined attributes containing the identity of the >>>>> time source and the parameters used to secure the time source. >>>>> However, it seems that the specifications that define the >>>>> algorithms and schemes that would be conveyed in these >>>>> attributes are still in Internet Draft form. Instead of >>>>> delaying the NEA specs while the NTP specs are finished, >>>>> I suggest that the secure time-related attributes go into >>>>> a separate Internet Draft that could provide the necessary >>>>> level of detail while avoiding the need for the NEA specs >>>>> to depend on the NTP specs. >>>>> >>>>> Minimum Cipher Suite: Most endpoints have a variety of >>>>> different ciphersuite selections for different purposes: >>>>> web browsing, email, VPN, etc. Even within one purpose, >>>>> who's to say which ciphersuite is the "minimum"? I don't >>>>> think we should include this as a standard attribute. >>>>> >>>>> Configuration State: This seems more like a configuration >>>>> management tool than a security measure. NEA is not chartered >>>>> to examine all configuration information, just configuration >>>>> information that "pertains to an organization's security policy". >>>>> If, as you suggested, vendors want to define vendor-specific >>>>> NEA attributes, they can do so by using their own SMI PEN >>>>> in the PA Message Vendor ID and/or PA-TNC Attribute Vendor >>>>> ID fields. Then the vendor can write their own Posture >>>>> Validator to check these attribute values. Alternatively, >>>>> some people may supply flexible Posture Validators that allow >>>>> users to check for specific values for vendor-specific attributes. >>>>> >>>>> PSTN_Fax_Enabled: Why is this security related? As noted >>>>> above, NEA is not chartered to manage all configuration >>>>> just security-related configuration. >>>>> >>>>> Admin_PW_Enabled: The sad thing is that this is probably >>>>> quite useful. People often take a device out of the box >>>>> and plug it into the network with the factory defaults >>>>> unchanged, including a default admin password. Maybe this >>>>> attribute should have a different name, though. The issue >>>>> isn't really whether an admin password is present but >>>>> whether there is an admin password that is NOT the default. >>>>> So how about naming the attribute "Admin_PW_Not_Default"? >>>>> BTW, this is not specific to hard copy devices. It pertains >>>>> to many kinds of devices. >>>>> >>>>> Your question about SMI subtrees doesn't seem relevant. >>>>> NEA doesn't use OIDs so subtrees aren't relevant. Maybe >>>>> you meant to talk about SMI Private Enterprise Numbers >>>>> (SMI PENs, used as Vendor IDs within the NEA specs). >>>>> Maybe the question is: If HCD defines some PA-TNC >>>>> attributes, should you use the IETF SMI PEN (0) or >>>>> some other one? I think that the answer is that HCD >>>>> should use its own SMI PEN for values that it defines. >>>>> Of course, if the values are of broader interest, it >>>>> would be good for you to submit them as Internet Drafts >>>>> and have them become RFCs and use the IETF SMI PEN. >>>>> That way, they could be used and known more widely. >>>>> >>>>> Your comments on software modules also confused me. PA-TNC >>>>> and PB-TNC don't assume that there is a BIOS, OS, and >>>>> applications. The word "BIOS" doesn't appear anywhere in >>>>> the PA-TNC spec. In fact, PA-TNC does exactly what you >>>>> suggested! It defines generic attributes (like Numeric >>>>> Version) that can be applied to any component on the >>>>> endpoint by using the appropriate PA Subtype (like Operating >>>>> System). Some devices won't have all the IETF Standard PA >>>>> Subtypes (like Anti-Malware). That's fine. Maybe there are >>>>> additional PA Subtypes that are needed for printers. That >>>>> would be good to know about. >>>>> >>>>> Thanks, >>>>> >>>>> Steve >>>>> >>>>>> -----Original Message----- >>>>>> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On >>>>>> Behalf Of Randy Turner >>>>>> Sent: Sunday, August 17, 2008 7:05 PM >>>>>> To: Paul Sangster >>>>>> Cc: nea@ietf.org >>>>>> Subject: Re: [Nea] proposals for attribute categories and >>>>>> attributes, etc. >>>>>> >>>>>> Hi Paul, >>>>>> >>>>>> Per your request, I'm forwarding along a proposal we discussed >>>>>> earlier for attribute categories, and corresponding attributes, >>>>>> as >>>>>> well as >>>>>> a some proposed model/data-type ideas for the WG to consider. >>>>>> >>>>>> NEA list members: >>>>>> I tried to format this in as simple an ASCII format as possible >>>>>> (spaces for tabs, etc.). Let me know if there is a problem with >>>>>> readability in certain >>>>>> email clients... >>>>>> >>>>>> >>>>>> Thanks! >>>>>> Randy >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This proposal introduces new attribute categories and >>>>>> corresponding >>>>>> attributes, and also suggests a new model for >>>>>> managing software on a particular computing device. The text of >>>>>> this >>>>>> proposal originates from evolving requirements >>>>>> being developed by the Printer Working Group (PWG). >>>>>> >>>>>> ------------------------------------- >>>>>> PROPOSED CATEGORIES >>>>>> ------------------------------------- >>>>>> >>>>>> =============== >>>>>> "System" Category >>>>>> =============== >>>>>> >>>>>> The "System" category would serve as a "container" for >>>>>> attributes that >>>>>> are used by core operating system services in the device. >>>>>> One corollary for this type of category is the "system" group >>>>>> of MIB-2 >>>>>> (RFC 1213). >>>>>> >>>>>> The following proposed attribute definitions would exist within >>>>>> the >>>>>> "System" category: >>>>>> >>>>>> "Forwarding Enabled" - a single-bit field or boolean value that >>>>>> indicates >>>>>> whether the system is >>>>>> performing any forwarding >>>>>> of "bits" or any kind of >>>>>> electronic transmissions between interfaces. >>>>>> >>>>>> "Secure Time Enabled" - a single-bit or boolean value that >>>>>> indicates >>>>>> if the device >>>>>> is configured >>>>>> to acquire >>>>>> the current time in a secure >>>>>> manner. If the >>>>>> device is >>>>>> using something as simple as >>>>>> SNTP, then the device >>>>>> would set this value to "False". >>>>>> >>>>>> "Time Source" - A variable length field that indicates the >>>>>> source from >>>>>> which >>>>>> the device acquires its' notion of the >>>>>> current date and time. >>>>>> This could be a URL of an SNTP or NTP >>>>>> time source, or could >>>>>> be some fixed identifier that indicates >>>>>> that the time is obtained >>>>>> from an onboard clock/calendar. >>>>>> >>>>>> "Minimum Cipher Suite" - A variable length string that >>>>>> represents one >>>>>> of the >>>>>> enumerations >>>>>> listed in >>>>>> the IANA "TLS Cipher Suite >>>>>> Registry". An >>>>>> example >>>>>> value would be: >>>>>> >>>>>> "TLS_RSA_WITH_AES_256_CBC_SHA256" >>>>>> >>>>>> >>>>>> "Configuration State" - attribute is a 32 byte field that >>>>>> uniquely >>>>>> identifies the state of >>>>>> any configuration settings >>>>>> in the device that are included in >>>>>> creation of the >>>>>> attribute. A >>>>>> change to any configuration >>>>>> setting that is included in >>>>>> the creation of the attribute MUST >>>>>> cause a change in this >>>>>> attributes value. >>>>>> The configuration settings >>>>>> included as part of this attribute >>>>>> SHOULD be administratively >>>>>> configurable. The rationale >>>>>> for this single >>>>>> attribute is >>>>>> to allow device vendors to utilize >>>>>> an industry standard >>>>>> attribute to reflect an arbitrary device >>>>>> configuration, >>>>>> consisting of >>>>>> whatever device-specific >>>>>> information the >>>>>> vendor wishes >>>>>> to include. If for some >>>>>> reason, a vendor did >>>>>> not want >>>>>> to publish these attributes, >>>>>> they can still utilize >>>>>> standards-compliant applications to >>>>>> detect invalid >>>>>> configurations >>>>>> and to potentially remediate >>>>>> the situation. The >>>>>> 32-byte >>>>>> field was chosen to allow the >>>>>> attribute value to >>>>>> be a 256- >>>>>> bit hash over the arbitrary >>>>>> configuration. This field >>>>>> would of course have to be >>>>>> enlarged to support >>>>>> SHA-512 >>>>>> or some other hash that >>>>>> produces a value >>>>>> larger than >>>>>> 256 bits. >>>>>> >>>>>> >>>>>> >>>>>> =============== >>>>>> "HCD" Category >>>>>> =============== >>>>>> >>>>>> The "HCD" category would serve as a container for attributes >>>>>> that are >>>>>> specific to "Hard Copy Devices", >>>>>> which could be a very low-end printer, or a very high-end multi- >>>>>> function device (fax, scan, print, etc.). >>>>>> >>>>>> "PSTN_Fax_Enabled" - a single-bit or boolean value that indicates >>>>>> whether or >>>>>> not the PSTN Fax >>>>>> interface >>>>>> is enabled. >>>>>> >>>>>> "Admin_PW_Enabled" - a single-bit or boolean value that indicates >>>>>> whether or >>>>>> not the factory default >>>>>> administrator password for the >>>>>> device has been changed >>>>>> to a "site-appropriate" value. >>>>>> >>>>>> >>>>>> ======= >>>>>> ISSUES: >>>>>> ======= >>>>>> >>>>>> The Printer Working Group is soliciting the opinion of the >>>>>> NEA working >>>>>> group as to the appropriate >>>>>> SMI location for a potential HCD category SMI sub-tree. >>>>>> >>>>>> The two alternatives under consideration are >>>>>> >>>>>> 1. The HCD SMI sub-tree would reside within the SMI tree >>>>>> being defined >>>>>> by the NEA working group for the initial "standardized" >>>>>> categories. >>>>>> >>>>>> or >>>>>> >>>>>> 2. The HCD SMI sub-tree would reside within an existing SMI >>>>>> tree that >>>>>> has been IANA-assigned to the Printer Working Group. >>>>>> >>>>>> The above attribute proposals also pre-suppose the existence of a >>>>>> "boolean" >>>>>> data type for the wire-encoding/information model for the PA >>>>>> protocol. >>>>>> The PWG >>>>>> is also proposing that this type of attribute data type be >>>>>> supported >>>>>> in the >>>>>> information model (and presumably wire encoding). >>>>>> >>>>>> -------------------------------------------------- >>>>>> Software "Module" Attribute Proposal >>>>>> -------------------------------------------------- >>>>>> >>>>>> The TNC model for trusted software configurations presupposes >>>>>> that >>>>>> all >>>>>> devices are basically PCs, and that the software >>>>>> architectural model is >>>>>> based on a "bios", "operating system", and "application" model. >>>>>> >>>>>> Since it is reasonable to assume that a network administrator >>>>>> might >>>>>> want to use a single tool for monitoring network device >>>>>> configurations >>>>>> in a topology, >>>>>> and also assuming that devices other than standard PCs are a part >>>>>> of >>>>>> this topology, this proposal suggests that the idea behind >>>>>> managing >>>>>> software >>>>>> components should be "moved up" a level of abstraction. Using the >>>>>> right type of abstraction would allow practically any type of >>>>>> device >>>>>> to be supported >>>>>> in the management of software components, whether these >>>>>> components be >>>>>> "applications", an "operating system", or a "bios". >>>>>> >>>>>> A software component or "module" instance might be a suitable >>>>>> level of >>>>>> abstraction to allow non-PC devices to be managed in the same way >>>>>> as >>>>>> PC devices. >>>>>> The software module abstraction would be a complex data type >>>>>> that can >>>>>> be multiply instanced. The complex data type would consist of (at >>>>>> least) 3 pieces of information: >>>>>> >>>>>> - Module Type (This could be a value indicating OS, Bios, or >>>>>> application, but might >>>>>> not be required at all for remediation. >>>>>> >>>>>> - Module Vendor - The manufacturer of this particular software >>>>>> module >>>>>> >>>>>> - Module Name - The name of the module such as "Mac OS X", or >>>>>> "Windows Vista Ultimate" >>>>>> >>>>>> - Module Version - This could either be a version number, >>>>>> build number, >>>>>> build date and time, or whatever >>>>>> the vendor uses to >>>>>> identify unique versions. >>>>>> >>>>>> The "module" idea can be either evolved as is, or used to >>>>>> stimulate >>>>>> discussion for >>>>>> an appropriate level of abstraction to represent individual, >>>>>> updateable software >>>>>> components within a device. >>>>>> >>>>>> The rationale behind supporting non-PC devices is not >>>>>> theoretical, in >>>>>> that there is a "spectrum" of network-connected devices that >>>>>> exist >>>>>> today. >>>>>> The spectrum originating with devices that utilize only a single, >>>>>> monolithic software load module, and end with devices that >>>>>> could have >>>>>> tertiary >>>>>> or that utilize a single, monolithic software load, through >>>>>> devices >>>>>> that support a tertiary structure (like PCs), to devices that >>>>>> utilize a quarternary or even larger number of unique software >>>>>> components. >>>>>> >>>>>> Using the "module" paradigm would allow all of these >>>>>> architectural >>>>>> permutations >>>>>> to exist simultaneously, and be managed (and remedied) using >>>>>> similar >>>>>> methods. >>>>>> >>>>>> This is just a first stab at an abstraction that might encompass >>>>>> all >>>>>> classes of >>>>>> devices that wish to utilize the NEA protocols. It is likely that >>>>>> other information >>>>>> may be required of this attribute model. >>>>>> >>>>>> An example of a monolithic device module would consist of a >>>>>> single- >>>>>> instance >>>>>> of the module data type: >>>>>> (Type="System",Vendor="HP", Name="HP Laserjet >>>>>> System",Version="5J2-R2") >>>>>> >>>>>> A typical PC would consist of a multiply-instanced attribute or >>>>>> attributes: >>>>>> >>>>>> (Type="BIOS", Vendor="Phoenix", Name="Phoenix DCore BIOS", >>>>>> Version-"7R2") >>>>>> (Type="OS", Vendor="Microsoft", Name="Windows Vista Ultimate", >>>>>> Version="SP1") >>>>>> (Type="APP", Vendor="Symantec", Name="AntiVirus", >>>>>> Version="3.2R2") >>>>>> (Type="APP", Vendor="Microsoft", Name="IE", Version="7.3") >>>>>> (Type="APP", Vendor="Symantec", Name="Firewall", Version="4.3") >>>>>> (Type="CFG", Vendor="Symantec", Name="fwrules", Version="16") >>>>>> >>>>>> Using the "module" abstraction would even allow the creation, and >>>>>> subsequent management/remediation of individual, updateable >>>>>> components >>>>>> like firewall >>>>>> rulesets, which could be updated without necessarily updating the >>>>>> application >>>>>> itself. NOTE: the "CFG" module type as illustrated above. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Nea mailing list >>>>>> Nea@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nea >>>>>> >>>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> _______________________________________________ >>>> Nea mailing list >>>> Nea@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nea >>>> >>>> >>>> End of Nea Digest, Vol 34, Issue 5 >>>> ********************************** >>> >>> >> > > _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Sep 5 11:56:42 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC88C3A6927; Fri, 5 Sep 2008 11:56:42 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46543A67D2 for ; Fri, 5 Sep 2008 11:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.89 X-Spam-Level: X-Spam-Status: No, score=-4.89 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGYpNzl9GP6g for ; Fri, 5 Sep 2008 11:56:38 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id DB7873A6A7C for ; Fri, 5 Sep 2008 11:55:09 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Fri, 05 Sep 2008 11:54:44 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Sep 2008 11:54:28 -0700 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Sep 2008 11:54:28 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Sep 2008 14:54:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Sep 2008 14:54:25 -0400 Message-ID: In-Reply-To: <4A6D7DA5-193A-4FF4-AA3B-70E0304A1025@amalfisystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] proposals for attribute categories and attributes, etc. Thread-Index: AckHwHUFLYCGK1h0ScqWMBGqiy0GlAHwvDzA References: <14181E32-7B3D-4DA3-85BB-21394865D6B9@amalfisystems.com> <9C033AD2-2BE7-4AA9-BAF7-B43991D53CE8@amalfisystems.com> <4A6D7DA5-193A-4FF4-AA3B-70E0304A1025@amalfisystems.com> From: "Stephen Hanna" To: "Randy Turner" X-OriginalArrivalTime: 05 Sep 2008 18:54:27.0182 (UTC) FILETIME=[D21C78E0:01C90F88] Cc: nea@ietf.org, Paul Sangster Subject: Re: [Nea] proposals for attribute categories and attributes, etc. X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Randy, I apologize for taking a few days to respond to your email. Forwarding Enabled ------------------ I think we agree that this is a useful security-related attribute. Most fixed-function endpoints should be able to easily determine a value for this attribute (Enabled or Disabled). Extensible endpoints probably cannot determine an appropriate value. So I suggest there be three values: Enabled, Disabled, and Unknown. Secure Time Enabled ------------------- I think that we agreee that if you can prepare and reach some rough WG consensus on a brief proposal in time for us to stay on schedule (in the next two weeks or so), then this can go in the base spec. If not, then it can be specified separately. There's no shame in having a separate spec, even if brief. In fact, it will be good to try out our extension process. Minimum Cipher Suite -------------------- You didn't respond to my comments. I guess they were compelling so you agree that this should not be included in the standard set of attributes? Configuration State ------------------- Developing a standard protocol for managing non-security attributes is out of scope for us. For security attributes (and arguably for non-security ones also), it's essential to know WHAT attributes are being reported. Otherwise, you can't achieve interoperability. We have already defined a whole protocol for reporting on labelled attributes. It's called PA-TNC. I suggest that people use that protocol to report attributes instead of just reporting a hash with no labels or information about what has been hashed. Therefore, I suggest that people who want to report on security attributes should mark them To properly solve the problem you described (reporting on an arbitrary set of attributes) in > -----Original Message----- > From: Randy Turner [mailto:rturner@amalfisystems.com] > Sent: Tuesday, August 26, 2008 5:12 PM > To: Stephen Hanna > Cc: Paul Sangster; nea@ietf.org > Subject: Re: [Nea] proposals for attribute categories and > attributes, etc. > > Hi Steve, > > Thanks for the note. > > I'll try and address your comments one at a time, using your labels. > > Forwarding Enabled > ---------------------------- > From the perspective of embedded devices, the application > set is more > or less > "locked down" so you know that, if "something" can forward, you know > exactly > the circumstances under which it does forward "bits". If you have an > architecture > that allows arbitrary apps to be added, then I agree, you're never > quite sure what's > going on. This situation might call for an attribute that indicates > whether or not the > application set can be modified by some entity other than the > manufacturer. If the > device can be updated with arbitrary apps, then a forwarding > attribute > may not > make sense. But if the device has a "locked down" application > environment, and there is > an attribute that can allow forwarding by the firmware, then maybe > this would make > more sense. I'm open to discussing this further.... > > Secure Time Enabled > ----------------------------- > The idea here is that we wanted to make sure that if a device was > acquiring it's notion > of time from "some source", that the source be trusted as a secure > source, and that the > manner in which the time is acquired cannot be tampered with enroute > from the source > to the device. As you suggest, we wanted to protect the use of > certificate checking (yes, > many high-end multifunction peripherals have cert mgmt capability), > and any other > functionality that requires accurate time, I had a feeling that the > use of "secure" might be > interpreted any number of ways. I think it's more important that if > it's possible to > configure a device to use a time acquisition method that is NOT > secure, or a time source > that is not "approved" by the site, then this type of > attribute would > be a part of the device > "posture". I'll try and come up with another way to indicate this > basic 2-part requirement. > I think "time source" might be one attribute (which was part of the > proposal), and then, if the device > is capable of being configured with a protocol that does not protect > the integrity of the > time acquired from a trusted source, then we need a way to prevent > this from happening (if > this is a site requirement). > > I'll mull over your suggestion about NOT delaying the base > NEA specs, > and deferring this > information to another document, but the solution may be so > concise as > to essentially produce > a 1-page draft :) If we can come up with something concise (in a > timeframe that doesn't > delay the NEA schedule) then it would be nice to spec it....if we > can't then I agree we would > have to address it in some later spec. > > Configuration State > -------------------------- > You are correct, this type of value may consist of attributes > that are > not necessarily, but then again > they may be security related - only the vendor would know for sure. > It could be that this hash > is a hash over security attributes that (for whatever reason) aren't > standardized or haven't been > spec'd in any way. This value allows for vendors (or > potentially site > admins) to define their own > set of posture attributes without having to worry about > standardization or registries, etc. > > You'll hear me say this more than once, but the concern is > that we're > defining a protocol that > allows administrators to determine if a device configuration is > conformant to some local security > policy. And I'm assuming that, if this WG doesn't do it, that some > future standards entity will > define a way to remediate a situation where one or more devices are > not conformant. > > This is a very nice and convenient system that I think would be of > high value to administrators. > And even though we've used the word "security" in the charter > (and in > your email), this protocol > could actually work with any type of device attributes. In > the future, > if a site decides to deploy a > posture monitoring and remediation system that monitors and > remediates > the "security" attributes, it > seems likely that someone might want to use the same infrastructure > for other types of attributes > as well. I know I'm breaching on stuff that's out of scope > and not a > part of the charter, but it seems > logical that once we have a complete monitoring/remediation system, > someone's going to ask > the question about "configuration" management. At least that's my > assumption. > > In lieu of any other "system" that does monitoring/remediation, the > "configuration state" attribute > would allow custom postures to be defined that could consist > of vendor- > specific security attributes, > non-security-related attributes, or a mix, and still use (at least) > the posture monitoring and reporting > capabilities that would be possible with our initial NEA work. > > PSTN_Fax_Enabled > --------------------------------- > Some hardcopy device vendors would consider this a security > attribute, > in that the device-local FAX > capability could allow an unauthorized party access to device > resources (or to exhaust device > resources) in some manner. > > This would not be what I would call a "Generic" attribute applicable > to all devices, but instead only > relegated to hardcopy devices. > > Admin_PW_Enabled > ----------------------------- > I agree about the name of this attribute - we could use > something like > "Factory-default-PW-Enabled" > or some equivalent. Even though I considered this a hardcopy issue, > it's not something that a > Linux, Windows, or Mac OS X admin would run into, since those > installation processes require the > installer (local or remote) to define root or admin credentials as > well as their associated passwords. > However, to your point, it could apply to other types of network > devices as well. And to reiterate, I > agree that a different name could be used. > > > SMI Subtrees > ------------------ > I may have worded it incorrectly, but I think you have > summarized the > concern that we were thinking > about. > > Software Modules > ------------------------ > Let me go back and review the source of this particular issue. I'll > get back to you (and the list). > > > Thanks again for the comments! More are welcome! > > Randy > > > > On Aug 26, 2008, at 11:44 AM, Stephen Hanna wrote: > > > Randy, > > > > Thanks for sending your comments. I found them quite interesting! > > I'm sorry that it has taken me a few days to respond. I was on > > holiday for a few days last week. > > > > Let me address your suggestions individually. Note that these > > are my personal comments and I'm sending them as an individual > > not as a WG chair. Please consider them in that context. > > > > Forwarding Enabled: I like the idea but forwarding can happen > > at the application layer, which is almost impossible to detect. > > Of course, this might not be an issue for an embedded device. > > Maybe three values are called for: Forwarding Enabled (known > > to be happening), Forwarding Possible (could be happening but > > not sure), and Forwarding Disabled (strongly believed that > > no forwarding is happening, as when there's no application > > software and the operating software does not forward). > > > > Secure Time Enabled: Having a good source of time is important > > for many security protocols (for checking expiration dates on > > certificates, for example). However, this attribute does raise > > a question: what is the definition of "secure" here? > > Is it secure to use an onboard source of time? Probably. > > What about SNTP or NTP? Probably not, unless you use some > > form of authentication. Are the authentication techniques > > described in RFC 1305 (NTPv3) enough? Maybe not, since they > > are based on DES and MD5. SNTPv4 (RFC 4330) doesn't specify > > a security algorithm. You could use the system described in > > draft-ietf-ntp-autokey-04.txt but that's just an Internet Draft. > > And which algorithms and identity schemes from that spec > > are being used? Are those still secure? And, as you say, > > Time Source must also be considered. Using a secure time > > protocol to fetch time from an untrustworthy time source > > isn't really secure. > > > > Instead of leaving all the decisions to the NEA Client and > > having the client indicate "Secure Time Enabled" to the > > NEA Server, it would be more consistent with the rest of > > NEA if we defined attributes containing the identity of the > > time source and the parameters used to secure the time source. > > However, it seems that the specifications that define the > > algorithms and schemes that would be conveyed in these > > attributes are still in Internet Draft form. Instead of > > delaying the NEA specs while the NTP specs are finished, > > I suggest that the secure time-related attributes go into > > a separate Internet Draft that could provide the necessary > > level of detail while avoiding the need for the NEA specs > > to depend on the NTP specs. > > > > Minimum Cipher Suite: Most endpoints have a variety of > > different ciphersuite selections for different purposes: > > web browsing, email, VPN, etc. Even within one purpose, > > who's to say which ciphersuite is the "minimum"? I don't > > think we should include this as a standard attribute. > > > > Configuration State: This seems more like a configuration > > management tool than a security measure. NEA is not chartered > > to examine all configuration information, just configuration > > information that "pertains to an organization's security policy". > > If, as you suggested, vendors want to define vendor-specific > > NEA attributes, they can do so by using their own SMI PEN > > in the PA Message Vendor ID and/or PA-TNC Attribute Vendor > > ID fields. Then the vendor can write their own Posture > > Validator to check these attribute values. Alternatively, > > some people may supply flexible Posture Validators that allow > > users to check for specific values for vendor-specific attributes. > > > > PSTN_Fax_Enabled: Why is this security related? As noted > > above, NEA is not chartered to manage all configuration > > just security-related configuration. > > > > Admin_PW_Enabled: The sad thing is that this is probably > > quite useful. People often take a device out of the box > > and plug it into the network with the factory defaults > > unchanged, including a default admin password. Maybe this > > attribute should have a different name, though. The issue > > isn't really whether an admin password is present but > > whether there is an admin password that is NOT the default. > > So how about naming the attribute "Admin_PW_Not_Default"? > > BTW, this is not specific to hard copy devices. It pertains > > to many kinds of devices. > > > > Your question about SMI subtrees doesn't seem relevant. > > NEA doesn't use OIDs so subtrees aren't relevant. Maybe > > you meant to talk about SMI Private Enterprise Numbers > > (SMI PENs, used as Vendor IDs within the NEA specs). > > Maybe the question is: If HCD defines some PA-TNC > > attributes, should you use the IETF SMI PEN (0) or > > some other one? I think that the answer is that HCD > > should use its own SMI PEN for values that it defines. > > Of course, if the values are of broader interest, it > > would be good for you to submit them as Internet Drafts > > and have them become RFCs and use the IETF SMI PEN. > > That way, they could be used and known more widely. > > > > Your comments on software modules also confused me. PA-TNC > > and PB-TNC don't assume that there is a BIOS, OS, and > > applications. The word "BIOS" doesn't appear anywhere in > > the PA-TNC spec. In fact, PA-TNC does exactly what you > > suggested! It defines generic attributes (like Numeric > > Version) that can be applied to any component on the > > endpoint by using the appropriate PA Subtype (like Operating > > System). Some devices won't have all the IETF Standard PA > > Subtypes (like Anti-Malware). That's fine. Maybe there are > > additional PA Subtypes that are needed for printers. That > > would be good to know about. > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On > >> Behalf Of Randy Turner > >> Sent: Sunday, August 17, 2008 7:05 PM > >> To: Paul Sangster > >> Cc: nea@ietf.org > >> Subject: Re: [Nea] proposals for attribute categories and > >> attributes, etc. > >> > >> Hi Paul, > >> > >> Per your request, I'm forwarding along a proposal we discussed > >> earlier for attribute categories, and corresponding attributes, as > >> well as > >> a some proposed model/data-type ideas for the WG to consider. > >> > >> NEA list members: > >> I tried to format this in as simple an ASCII format as possible > >> (spaces for tabs, etc.). Let me know if there is a problem with > >> readability in certain > >> email clients... > >> > >> > >> Thanks! > >> Randy > >> > >> > >> > >> > >> > >> > >> > >> > >> This proposal introduces new attribute categories and corresponding > >> attributes, and also suggests a new model for > >> managing software on a particular computing device. The > text of this > >> proposal originates from evolving requirements > >> being developed by the Printer Working Group (PWG). > >> > >> ------------------------------------- > >> PROPOSED CATEGORIES > >> ------------------------------------- > >> > >> =============== > >> "System" Category > >> =============== > >> > >> The "System" category would serve as a "container" for > >> attributes that > >> are used by core operating system services in the device. > >> One corollary for this type of category is the "system" group > >> of MIB-2 > >> (RFC 1213). > >> > >> The following proposed attribute definitions would exist within the > >> "System" category: > >> > >> "Forwarding Enabled" - a single-bit field or boolean value that > >> indicates > >> whether the system is > >> performing any forwarding > >> of "bits" or any kind of > >> electronic transmissions between interfaces. > >> > >> "Secure Time Enabled" - a single-bit or boolean value that > indicates > >> if the device > >> is configured > >> to acquire > >> the current time in a secure > >> manner. If the > >> device is > >> using something as simple as > >> SNTP, then the device > >> would set this value to "False". > >> > >> "Time Source" - A variable length field that indicates the > >> source from > >> which > >> the device acquires its' notion of the > >> current date and time. > >> This could be a URL of an SNTP or NTP > >> time source, or could > >> be some fixed identifier that indicates > >> that the time is obtained > >> from an onboard clock/calendar. > >> > >> "Minimum Cipher Suite" - A variable length string that > >> represents one > >> of the > >> enumerations > >> listed in > >> the IANA "TLS Cipher Suite > >> Registry". An > >> example > >> value would be: > >> > >> "TLS_RSA_WITH_AES_256_CBC_SHA256" > >> > >> > >> "Configuration State" - attribute is a 32 byte field that uniquely > >> identifies the state of > >> any configuration settings > >> in the device that are included in > >> creation of the > >> attribute. A > >> change to any configuration > >> setting that is included in > >> the creation of the attribute MUST > >> cause a change in this > >> attributes value. > >> The configuration settings > >> included as part of this attribute > >> SHOULD be administratively > >> configurable. The rationale > >> for this single > >> attribute is > >> to allow device vendors to utilize > >> an industry standard > >> attribute to reflect an arbitrary device > >> configuration, > >> consisting of > >> whatever device-specific > >> information the > >> vendor wishes > >> to include. If for some > >> reason, a vendor did > >> not want > >> to publish these attributes, > >> they can still utilize > >> standards-compliant applications to > >> detect invalid > >> configurations > >> and to potentially remediate > >> the situation. The > >> 32-byte > >> field was chosen to allow the > >> attribute value to > >> be a 256- > >> bit hash over the arbitrary > >> configuration. This field > >> would of course have to be > >> enlarged to support > >> SHA-512 > >> or some other hash that > >> produces a value > >> larger than > >> 256 bits. > >> > >> > >> > >> =============== > >> "HCD" Category > >> =============== > >> > >> The "HCD" category would serve as a container for attributes > >> that are > >> specific to "Hard Copy Devices", > >> which could be a very low-end printer, or a very high-end multi- > >> function device (fax, scan, print, etc.). > >> > >> "PSTN_Fax_Enabled" - a single-bit or boolean value that indicates > >> whether or > >> not the PSTN Fax > >> interface > >> is enabled. > >> > >> "Admin_PW_Enabled" - a single-bit or boolean value that indicates > >> whether or > >> not the factory default > >> administrator password for the > >> device has been changed > >> to a "site-appropriate" value. > >> > >> > >> ======= > >> ISSUES: > >> ======= > >> > >> The Printer Working Group is soliciting the opinion of the > >> NEA working > >> group as to the appropriate > >> SMI location for a potential HCD category SMI sub-tree. > >> > >> The two alternatives under consideration are > >> > >> 1. The HCD SMI sub-tree would reside within the SMI tree > >> being defined > >> by the NEA working group for the initial "standardized" categories. > >> > >> or > >> > >> 2. The HCD SMI sub-tree would reside within an existing SMI > >> tree that > >> has been IANA-assigned to the Printer Working Group. > >> > >> The above attribute proposals also pre-suppose the existence of a > >> "boolean" > >> data type for the wire-encoding/information model for the PA > >> protocol. > >> The PWG > >> is also proposing that this type of attribute data type be > supported > >> in the > >> information model (and presumably wire encoding). > >> > >> -------------------------------------------------- > >> Software "Module" Attribute Proposal > >> -------------------------------------------------- > >> > >> The TNC model for trusted software configurations > presupposes that > >> all > >> devices are basically PCs, and that the software > >> architectural model is > >> based on a "bios", "operating system", and "application" model. > >> > >> Since it is reasonable to assume that a network administrator might > >> want to use a single tool for monitoring network device > >> configurations > >> in a topology, > >> and also assuming that devices other than standard PCs are > a part of > >> this topology, this proposal suggests that the idea behind managing > >> software > >> components should be "moved up" a level of abstraction. Using the > >> right type of abstraction would allow practically any type > of device > >> to be supported > >> in the management of software components, whether these > >> components be > >> "applications", an "operating system", or a "bios". > >> > >> A software component or "module" instance might be a suitable > >> level of > >> abstraction to allow non-PC devices to be managed in the > same way as > >> PC devices. > >> The software module abstraction would be a complex data type > >> that can > >> be multiply instanced. The complex data type would consist of (at > >> least) 3 pieces of information: > >> > >> - Module Type (This could be a value indicating OS, Bios, or > >> application, but might > >> not be required at all for remediation. > >> > >> - Module Vendor - The manufacturer of this particular > software module > >> > >> - Module Name - The name of the module such as "Mac OS X", or > >> "Windows Vista Ultimate" > >> > >> - Module Version - This could either be a version number, > >> build number, > >> build date and time, or whatever > >> the vendor uses to > >> identify unique versions. > >> > >> The "module" idea can be either evolved as is, or used to stimulate > >> discussion for > >> an appropriate level of abstraction to represent individual, > >> updateable software > >> components within a device. > >> > >> The rationale behind supporting non-PC devices is not > >> theoretical, in > >> that there is a "spectrum" of network-connected devices that exist > >> today. > >> The spectrum originating with devices that utilize only a single, > >> monolithic software load module, and end with devices that > >> could have > >> tertiary > >> or that utilize a single, monolithic software load, through devices > >> that support a tertiary structure (like PCs), to devices that > >> utilize a quarternary or even larger number of unique software > >> components. > >> > >> Using the "module" paradigm would allow all of these architectural > >> permutations > >> to exist simultaneously, and be managed (and remedied) > using similar > >> methods. > >> > >> This is just a first stab at an abstraction that might > encompass all > >> classes of > >> devices that wish to utilize the NEA protocols. It is likely that > >> other information > >> may be required of this attribute model. > >> > >> An example of a monolithic device module would consist of a single- > >> instance > >> of the module data type: > >> (Type="System",Vendor="HP", Name="HP Laserjet > >> System",Version="5J2-R2") > >> > >> A typical PC would consist of a multiply-instanced attribute or > >> attributes: > >> > >> (Type="BIOS", Vendor="Phoenix", Name="Phoenix DCore BIOS", > >> Version-"7R2") > >> (Type="OS", Vendor="Microsoft", Name="Windows Vista Ultimate", > >> Version="SP1") > >> (Type="APP", Vendor="Symantec", Name="AntiVirus", Version="3.2R2") > >> (Type="APP", Vendor="Microsoft", Name="IE", Version="7.3") > >> (Type="APP", Vendor="Symantec", Name="Firewall", Version="4.3") > >> (Type="CFG", Vendor="Symantec", Name="fwrules", Version="16") > >> > >> Using the "module" abstraction would even allow the creation, and > >> subsequent management/remediation of individual, updateable > >> components > >> like firewall > >> rulesets, which could be updated without necessarily updating the > >> application > >> itself. NOTE: the "CFG" module type as illustrated above. > >> > >> > >> _______________________________________________ > >> Nea mailing list > >> Nea@ietf.org > >> https://www.ietf.org/mailman/listinfo/nea > >> > > > > _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Sep 5 12:06:07 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B713A68CE; Fri, 5 Sep 2008 12:06:07 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5233A690E for ; Fri, 5 Sep 2008 12:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju5rl6U9PzCs for ; Fri, 5 Sep 2008 12:05:59 -0700 (PDT) Received: from extu-mxob-2.symantec.com (extu-mxob-2.symantec.com [216.10.194.135]) by core3.amsl.com (Postfix) with ESMTP id B2D7B3A6808 for ; Fri, 5 Sep 2008 12:05:58 -0700 (PDT) Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by extu-mxob-2.symantec.com (8.14.1/8.14.1) with ESMTP id m85J5YwN022347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Sep 2008 12:05:36 -0700 Received: from reserved-155-64-230-20.ges.symantec.com ([155.64.230.20] helo=TUS1XCHECNPIN03.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1Kbgcg-0000Tc-LE for nea@ietf.org; Fri, 05 Sep 2008 12:05:34 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Sep 2008 12:05:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Sep 2008 12:04:43 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another last call for attributes and component types thread-index: AckNNA8g6bcNC9hY+U6APs7ntBqjGQCVTIiQ References: From: "Paul Sangster" To: "NEA" X-OriginalArrivalTime: 05 Sep 2008 19:05:34.0442 (UTC) FILETIME=[5FD444A0:01C90F8A] Subject: [Nea] Another last call for attributes and component types X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359155473==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0359155473== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C90F8A.42E56676" This is a multi-part message in MIME format. ------_=_NextPart_001_01C90F8A.42E56676 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The editors and chairs discussed the request to extend the discussion of new attributes and component types. We decided that we wanted to let this thread continue alittle longer to see what changes we can include in the Sept revision of the specs. We believe that we can still hit a late September release as long as the discussion is complete by mid-September. Therefore, we are extending the cut-off date for discussion of new attributes and component types (PA subtypes) until 5PM PDT on Friday, September 19th. ________________________________ From: Brian Ford [mailto:brford@cisco.com]=20 Sent: Tuesday, September 02, 2008 12:43 PM To: Paul Sangster Cc: NEA; Kaushik Narayan Subject: re: Request for new Attributes and Component Types (subtypes) for PA =09 =09 Paul, =09 Please note that the link to the slides in the message below doesn't work. The IETF 72 NEA slides seem to be in the same directory in a file titled "nea-1.ppt". =09 Given that the members of the working group didn't have access to these slides I would request that your "end of August" request date be extended by at least 30 days. =09 Liberty, =09 Brian =09 =09 =09 =09 Date: Fri, 8 Aug 2008 15:27:09 -0700 From: "Paul Sangster" Subject: [Nea] Request for new Attributes and Component Types (subtypes) for PA To: Message-ID: =09 =20 Content-Type: text/plain; charset=3D"us-ascii" =09 As discussed in Dublin, we have a tight schedule for the PA and PB specs prior to WGLC, so need to make major progress right away on all major open topics for the specifications. The primary open question for PA is to complete the standard attribute name space and list of component types (subtypes) for the 1.0 spec. The editors are currently working on additional attribute proposals, but we would like to hear from the WG. =20 At the start of open mic in Dublin, we presented 2 slides (32 and 33) listing the currently defined attributes and components and requested feedback from the WG (see slides at www3.ietf.org/proceedings/08jul/slides/nea-0.ppt). The editors would like to request a final call for new attributes and components types for PA by 5PM PDT on Aug 22nd. Proposals should describe the need and use of the new attribute (or component type) and any associated information required. This will enable us to get another revision out by the end of August and stay on schedule. =20 Thanks, =20 Paul and Kaushik PA Editors =20 ------_=_NextPart_001_01C90F8A.42E56676 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable re: Request for new Attributes and Component Types = (subtypes) for PA
The editors and chairs discussed the request to = extend the=20 discussion of new attributes and component types.  We decided that = we=20 wanted to let this thread continue alittle longer to see what changes we = can=20 include in the Sept revision of the specs.  We believe that we can = still=20 hit a late September release as long as the discussion is complete by=20 mid-September.  Therefore, we are extending the cut-off date=20 for discussion of new attributes and component types (PA=20 subtypes) until 5PM PDT on Friday, September = 19th.

From: Brian Ford = [mailto:brford@cisco.com]=20
Sent: Tuesday, September 02, 2008 12:43 PM
To: = Paul=20 Sangster
Cc: NEA; Kaushik Narayan
Subject: re: = Request for=20 new Attributes and Component Types (subtypes) for = PA

Paul,

Please note that the link to = the slides=20 in the message below doesn’t work.  The IETF 72 NEA slides = seem to be in=20 the same directory in a file titled = “nea-1.ppt”.

Given that the members=20 of the working group didn’t have access to these slides I would = request that=20 your “end of August” request date be extended by at least = 30=20 days.

Liberty,

Brian
Date: Fri, 8 Aug 2008 15:27:09 = -0700
From: "Paul=20 Sangster" <Paul_Sangster@symantec.com>
Subject:=20 [Nea] Request for new Attributes and Component=20 Types
    (subtypes) for =    PA
To:=20 <nea@ietf.org>
Message-ID:
&= nbsp;   <AB96CED633A7C246BDC661DBEE1CF01F04654621@TUS1XCHCLUPIN12.= enterprise.veritas.com>
    
= Content-Type:=20 text/plain; charset=3D"us-ascii"

As discussed in Dublin, we = have a=20 tight schedule for the PA and PB specs
prior to WGLC, so need to = make=20 major progress right away on all major
open topics for the=20 specifications.  The primary open question for PA is
to = complete the=20 standard attribute name space and list of component
types = (subtypes) for=20 the 1.0 spec.  The editors are currently working = on
additional=20 attribute proposals, but we would like to hear from the = WG.
 
At=20 the start of open mic in Dublin, we presented 2 slides (32 and=20 33)
listing the currently defined attributes and components and=20 requested
feedback from the WG (see slides=20 at
www3.ietf.org/proceedings/08jul/slides/nea-0.ppt).  The = editors=20 would
like to request a final call for new attributes and = components=20 types for
PA by 5PM PDT on Aug 22nd.  Proposals should = describe the=20 need and use
of the new attribute (or component type) and any = associated=20 information
required.  This will enable us to get another = revision=20 out by the end of
August and stay on=20 schedule.
 
Thanks,
 
Paul and Kaushik
PA=20 = Editors
 
------_=_NextPart_001_01C90F8A.42E56676-- --===============0359155473== 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://www.ietf.org/mailman/listinfo/nea --===============0359155473==-- From nea-bounces@ietf.org Fri Sep 5 12:08:28 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA443A68D5; Fri, 5 Sep 2008 12:08:28 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3C873A68CE for ; Fri, 5 Sep 2008 12:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9kdUxZyfRnu for ; Fri, 5 Sep 2008 12:08:24 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id A2AEE3A6808 for ; Fri, 5 Sep 2008 12:08:22 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Fri, 05 Sep 2008 12:07:22 PDT Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Sep 2008 12:07:34 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Sep 2008 15:07:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Sep 2008 15:07:32 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] proposals for attribute categories and attributes, etc. Thread-Index: AckHwHUFLYCGK1h0ScqWMBGqiy0GlAHwvDzAAAFhYpA= References: <14181E32-7B3D-4DA3-85BB-21394865D6B9@amalfisystems.com> <9C033AD2-2BE7-4AA9-BAF7-B43991D53CE8@amalfisystems.com> <4A6D7DA5-193A-4FF4-AA3B-70E0304A1025@amalfisystems.com> From: "Stephen Hanna" To: "Randy Turner" X-OriginalArrivalTime: 05 Sep 2008 19:07:33.0656 (UTC) FILETIME=[A6E2E180:01C90F8A] Cc: nea@ietf.org, Paul Sangster Subject: Re: [Nea] proposals for attribute categories and attributes, etc. X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Sorry, this email escaped prematurely. Let me try again. Forwarding Enabled ------------------ I think we agree that this is a useful security-related attribute. Most fixed-function endpoints should be able to easily determine a value for this attribute (Enabled or Disabled). Extensible endpoints probably cannot determine an appropriate value. So I suggest there be three values: Enabled, Disabled, and Unknown. Secure Time Enabled ------------------- I think that we agreee that if you can prepare and reach some rough WG consensus on a brief proposal in time for us to stay on schedule (in the next two weeks or so), then this can go in the base spec. If not, then it can be specified separately. There's no shame in having a separate spec, even if brief. In fact, it will be good to try out our extension process. Minimum Cipher Suite -------------------- You didn't respond to my comments. I guess they were compelling so you agree that this should not be included in the standard set of attributes? Configuration State ------------------- Developing a standard protocol for managing non-security attributes is out of scope for us. For security attributes (and arguably for non-security ones also), it's essential to know WHAT attributes are being reported. Otherwise, you can't achieve interoperability. We have already defined a whole protocol for reporting on labelled attributes. It's called PA-TNC. I suggest that people use that protocol to report attributes instead of just reporting a hash with no labels or information about what has been hashed. PSTN_Fax_Enabled ---------------- I think you made a good case for standardizing this as a security-related attribute for hard copy devices, since fax can be used to cause resource depletion and denial of service. I wonder whether this even applies to non hard copy devices, since receiving faxes on a desktop PC can eat up hard drive space. Admin_PW_Enabled ---------------- I think we agree on this, with a change in name to "Factory-Default-PW-Enabled" or something like that. SMI Subtrees ------------ I think we agree that this has been settled. HCD can get an SMI PEN for attributes of narrow interest or submit Internet Drafts for those of broad interest. Software Modules ---------------- I look forward to seeing your comments on this. Thanks, Steve > -----Original Message----- > From: Randy Turner [mailto:rturner@amalfisystems.com] > Sent: Tuesday, August 26, 2008 5:12 PM > To: Stephen Hanna > Cc: Paul Sangster; nea@ietf.org > Subject: Re: [Nea] proposals for attribute categories and > attributes, etc. > > Hi Steve, > > Thanks for the note. > > I'll try and address your comments one at a time, using your labels. > > Forwarding Enabled > ---------------------------- > From the perspective of embedded devices, the application > set is more > or less > "locked down" so you know that, if "something" can forward, you know > exactly > the circumstances under which it does forward "bits". If you have an > architecture > that allows arbitrary apps to be added, then I agree, you're never > quite sure what's > going on. This situation might call for an attribute that indicates > whether or not the > application set can be modified by some entity other than the > manufacturer. If the > device can be updated with arbitrary apps, then a forwarding > attribute > may not > make sense. But if the device has a "locked down" application > environment, and there is > an attribute that can allow forwarding by the firmware, then maybe > this would make > more sense. I'm open to discussing this further.... > > Secure Time Enabled > ----------------------------- > The idea here is that we wanted to make sure that if a device was > acquiring it's notion > of time from "some source", that the source be trusted as a secure > source, and that the > manner in which the time is acquired cannot be tampered with enroute > from the source > to the device. As you suggest, we wanted to protect the use of > certificate checking (yes, > many high-end multifunction peripherals have cert mgmt capability), > and any other > functionality that requires accurate time, I had a feeling that the > use of "secure" might be > interpreted any number of ways. I think it's more important that if > it's possible to > configure a device to use a time acquisition method that is NOT > secure, or a time source > that is not "approved" by the site, then this type of > attribute would > be a part of the device > "posture". I'll try and come up with another way to indicate this > basic 2-part requirement. > I think "time source" might be one attribute (which was part of the > proposal), and then, if the device > is capable of being configured with a protocol that does not protect > the integrity of the > time acquired from a trusted source, then we need a way to prevent > this from happening (if > this is a site requirement). > > I'll mull over your suggestion about NOT delaying the base > NEA specs, > and deferring this > information to another document, but the solution may be so > concise as > to essentially produce > a 1-page draft :) If we can come up with something concise (in a > timeframe that doesn't > delay the NEA schedule) then it would be nice to spec it....if we > can't then I agree we would > have to address it in some later spec. > > Configuration State > -------------------------- > You are correct, this type of value may consist of attributes > that are > not necessarily, but then again > they may be security related - only the vendor would know for sure. > It could be that this hash > is a hash over security attributes that (for whatever reason) aren't > standardized or haven't been > spec'd in any way. This value allows for vendors (or > potentially site > admins) to define their own > set of posture attributes without having to worry about > standardization or registries, etc. > > You'll hear me say this more than once, but the concern is > that we're > defining a protocol that > allows administrators to determine if a device configuration is > conformant to some local security > policy. And I'm assuming that, if this WG doesn't do it, that some > future standards entity will > define a way to remediate a situation where one or more devices are > not conformant. > > This is a very nice and convenient system that I think would be of > high value to administrators. > And even though we've used the word "security" in the charter > (and in > your email), this protocol > could actually work with any type of device attributes. In > the future, > if a site decides to deploy a > posture monitoring and remediation system that monitors and > remediates > the "security" attributes, it > seems likely that someone might want to use the same infrastructure > for other types of attributes > as well. I know I'm breaching on stuff that's out of scope > and not a > part of the charter, but it seems > logical that once we have a complete monitoring/remediation system, > someone's going to ask > the question about "configuration" management. At least that's my > assumption. > > In lieu of any other "system" that does monitoring/remediation, the > "configuration state" attribute > would allow custom postures to be defined that could consist > of vendor- > specific security attributes, > non-security-related attributes, or a mix, and still use (at least) > the posture monitoring and reporting > capabilities that would be possible with our initial NEA work. > > PSTN_Fax_Enabled > --------------------------------- > Some hardcopy device vendors would consider this a security > attribute, > in that the device-local FAX > capability could allow an unauthorized party access to device > resources (or to exhaust device > resources) in some manner. > > This would not be what I would call a "Generic" attribute applicable > to all devices, but instead only > relegated to hardcopy devices. > > Admin_PW_Enabled > ----------------------------- > I agree about the name of this attribute - we could use > something like > "Factory-default-PW-Enabled" > or some equivalent. Even though I considered this a hardcopy issue, > it's not something that a > Linux, Windows, or Mac OS X admin would run into, since those > installation processes require the > installer (local or remote) to define root or admin credentials as > well as their associated passwords. > However, to your point, it could apply to other types of network > devices as well. And to reiterate, I > agree that a different name could be used. > > > SMI Subtrees > ------------------ > I may have worded it incorrectly, but I think you have > summarized the > concern that we were thinking > about. > > Software Modules > ------------------------ > Let me go back and review the source of this particular issue. I'll > get back to you (and the list). > > > Thanks again for the comments! More are welcome! > > Randy > > > > On Aug 26, 2008, at 11:44 AM, Stephen Hanna wrote: > > > Randy, > > > > Thanks for sending your comments. I found them quite interesting! > > I'm sorry that it has taken me a few days to respond. I was on > > holiday for a few days last week. > > > > Let me address your suggestions individually. Note that these > > are my personal comments and I'm sending them as an individual > > not as a WG chair. Please consider them in that context. > > > > Forwarding Enabled: I like the idea but forwarding can happen > > at the application layer, which is almost impossible to detect. > > Of course, this might not be an issue for an embedded device. > > Maybe three values are called for: Forwarding Enabled (known > > to be happening), Forwarding Possible (could be happening but > > not sure), and Forwarding Disabled (strongly believed that > > no forwarding is happening, as when there's no application > > software and the operating software does not forward). > > > > Secure Time Enabled: Having a good source of time is important > > for many security protocols (for checking expiration dates on > > certificates, for example). However, this attribute does raise > > a question: what is the definition of "secure" here? > > Is it secure to use an onboard source of time? Probably. > > What about SNTP or NTP? Probably not, unless you use some > > form of authentication. Are the authentication techniques > > described in RFC 1305 (NTPv3) enough? Maybe not, since they > > are based on DES and MD5. SNTPv4 (RFC 4330) doesn't specify > > a security algorithm. You could use the system described in > > draft-ietf-ntp-autokey-04.txt but that's just an Internet Draft. > > And which algorithms and identity schemes from that spec > > are being used? Are those still secure? And, as you say, > > Time Source must also be considered. Using a secure time > > protocol to fetch time from an untrustworthy time source > > isn't really secure. > > > > Instead of leaving all the decisions to the NEA Client and > > having the client indicate "Secure Time Enabled" to the > > NEA Server, it would be more consistent with the rest of > > NEA if we defined attributes containing the identity of the > > time source and the parameters used to secure the time source. > > However, it seems that the specifications that define the > > algorithms and schemes that would be conveyed in these > > attributes are still in Internet Draft form. Instead of > > delaying the NEA specs while the NTP specs are finished, > > I suggest that the secure time-related attributes go into > > a separate Internet Draft that could provide the necessary > > level of detail while avoiding the need for the NEA specs > > to depend on the NTP specs. > > > > Minimum Cipher Suite: Most endpoints have a variety of > > different ciphersuite selections for different purposes: > > web browsing, email, VPN, etc. Even within one purpose, > > who's to say which ciphersuite is the "minimum"? I don't > > think we should include this as a standard attribute. > > > > Configuration State: This seems more like a configuration > > management tool than a security measure. NEA is not chartered > > to examine all configuration information, just configuration > > information that "pertains to an organization's security policy". > > If, as you suggested, vendors want to define vendor-specific > > NEA attributes, they can do so by using their own SMI PEN > > in the PA Message Vendor ID and/or PA-TNC Attribute Vendor > > ID fields. Then the vendor can write their own Posture > > Validator to check these attribute values. Alternatively, > > some people may supply flexible Posture Validators that allow > > users to check for specific values for vendor-specific attributes. > > > > PSTN_Fax_Enabled: Why is this security related? As noted > > above, NEA is not chartered to manage all configuration > > just security-related configuration. > > > > Admin_PW_Enabled: The sad thing is that this is probably > > quite useful. People often take a device out of the box > > and plug it into the network with the factory defaults > > unchanged, including a default admin password. Maybe this > > attribute should have a different name, though. The issue > > isn't really whether an admin password is present but > > whether there is an admin password that is NOT the default. > > So how about naming the attribute "Admin_PW_Not_Default"? > > BTW, this is not specific to hard copy devices. It pertains > > to many kinds of devices. > > > > Your question about SMI subtrees doesn't seem relevant. > > NEA doesn't use OIDs so subtrees aren't relevant. Maybe > > you meant to talk about SMI Private Enterprise Numbers > > (SMI PENs, used as Vendor IDs within the NEA specs). > > Maybe the question is: If HCD defines some PA-TNC > > attributes, should you use the IETF SMI PEN (0) or > > some other one? I think that the answer is that HCD > > should use its own SMI PEN for values that it defines. > > Of course, if the values are of broader interest, it > > would be good for you to submit them as Internet Drafts > > and have them become RFCs and use the IETF SMI PEN. > > That way, they could be used and known more widely. > > > > Your comments on software modules also confused me. PA-TNC > > and PB-TNC don't assume that there is a BIOS, OS, and > > applications. The word "BIOS" doesn't appear anywhere in > > the PA-TNC spec. In fact, PA-TNC does exactly what you > > suggested! It defines generic attributes (like Numeric > > Version) that can be applied to any component on the > > endpoint by using the appropriate PA Subtype (like Operating > > System). Some devices won't have all the IETF Standard PA > > Subtypes (like Anti-Malware). That's fine. Maybe there are > > additional PA Subtypes that are needed for printers. That > > would be good to know about. > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On > >> Behalf Of Randy Turner > >> Sent: Sunday, August 17, 2008 7:05 PM > >> To: Paul Sangster > >> Cc: nea@ietf.org > >> Subject: Re: [Nea] proposals for attribute categories and > >> attributes, etc. > >> > >> Hi Paul, > >> > >> Per your request, I'm forwarding along a proposal we discussed > >> earlier for attribute categories, and corresponding attributes, as > >> well as > >> a some proposed model/data-type ideas for the WG to consider. > >> > >> NEA list members: > >> I tried to format this in as simple an ASCII format as possible > >> (spaces for tabs, etc.). Let me know if there is a problem with > >> readability in certain > >> email clients... > >> > >> > >> Thanks! > >> Randy > >> > >> > >> > >> > >> > >> > >> > >> > >> This proposal introduces new attribute categories and corresponding > >> attributes, and also suggests a new model for > >> managing software on a particular computing device. The > text of this > >> proposal originates from evolving requirements > >> being developed by the Printer Working Group (PWG). > >> > >> ------------------------------------- > >> PROPOSED CATEGORIES > >> ------------------------------------- > >> > >> =============== > >> "System" Category > >> =============== > >> > >> The "System" category would serve as a "container" for > >> attributes that > >> are used by core operating system services in the device. > >> One corollary for this type of category is the "system" group > >> of MIB-2 > >> (RFC 1213). > >> > >> The following proposed attribute definitions would exist within the > >> "System" category: > >> > >> "Forwarding Enabled" - a single-bit field or boolean value that > >> indicates > >> whether the system is > >> performing any forwarding > >> of "bits" or any kind of > >> electronic transmissions between interfaces. > >> > >> "Secure Time Enabled" - a single-bit or boolean value that > indicates > >> if the device > >> is configured > >> to acquire > >> the current time in a secure > >> manner. If the > >> device is > >> using something as simple as > >> SNTP, then the device > >> would set this value to "False". > >> > >> "Time Source" - A variable length field that indicates the > >> source from > >> which > >> the device acquires its' notion of the > >> current date and time. > >> This could be a URL of an SNTP or NTP > >> time source, or could > >> be some fixed identifier that indicates > >> that the time is obtained > >> from an onboard clock/calendar. > >> > >> "Minimum Cipher Suite" - A variable length string that > >> represents one > >> of the > >> enumerations > >> listed in > >> the IANA "TLS Cipher Suite > >> Registry". An > >> example > >> value would be: > >> > >> "TLS_RSA_WITH_AES_256_CBC_SHA256" > >> > >> > >> "Configuration State" - attribute is a 32 byte field that uniquely > >> identifies the state of > >> any configuration settings > >> in the device that are included in > >> creation of the > >> attribute. A > >> change to any configuration > >> setting that is included in > >> the creation of the attribute MUST > >> cause a change in this > >> attributes value. > >> The configuration settings > >> included as part of this attribute > >> SHOULD be administratively > >> configurable. The rationale > >> for this single > >> attribute is > >> to allow device vendors to utilize > >> an industry standard > >> attribute to reflect an arbitrary device > >> configuration, > >> consisting of > >> whatever device-specific > >> information the > >> vendor wishes > >> to include. If for some > >> reason, a vendor did > >> not want > >> to publish these attributes, > >> they can still utilize > >> standards-compliant applications to > >> detect invalid > >> configurations > >> and to potentially remediate > >> the situation. The > >> 32-byte > >> field was chosen to allow the > >> attribute value to > >> be a 256- > >> bit hash over the arbitrary > >> configuration. This field > >> would of course have to be > >> enlarged to support > >> SHA-512 > >> or some other hash that > >> produces a value > >> larger than > >> 256 bits. > >> > >> > >> > >> =============== > >> "HCD" Category > >> =============== > >> > >> The "HCD" category would serve as a container for attributes > >> that are > >> specific to "Hard Copy Devices", > >> which could be a very low-end printer, or a very high-end multi- > >> function device (fax, scan, print, etc.). > >> > >> "PSTN_Fax_Enabled" - a single-bit or boolean value that indicates > >> whether or > >> not the PSTN Fax > >> interface > >> is enabled. > >> > >> "Admin_PW_Enabled" - a single-bit or boolean value that indicates > >> whether or > >> not the factory default > >> administrator password for the > >> device has been changed > >> to a "site-appropriate" value. > >> > >> > >> ======= > >> ISSUES: > >> ======= > >> > >> The Printer Working Group is soliciting the opinion of the > >> NEA working > >> group as to the appropriate > >> SMI location for a potential HCD category SMI sub-tree. > >> > >> The two alternatives under consideration are > >> > >> 1. The HCD SMI sub-tree would reside within the SMI tree > >> being defined > >> by the NEA working group for the initial "standardized" categories. > >> > >> or > >> > >> 2. The HCD SMI sub-tree would reside within an existing SMI > >> tree that > >> has been IANA-assigned to the Printer Working Group. > >> > >> The above attribute proposals also pre-suppose the existence of a > >> "boolean" > >> data type for the wire-encoding/information model for the PA > >> protocol. > >> The PWG > >> is also proposing that this type of attribute data type be > supported > >> in the > >> information model (and presumably wire encoding). > >> > >> -------------------------------------------------- > >> Software "Module" Attribute Proposal > >> -------------------------------------------------- > >> > >> The TNC model for trusted software configurations > presupposes that > >> all > >> devices are basically PCs, and that the software > >> architectural model is > >> based on a "bios", "operating system", and "application" model. > >> > >> Since it is reasonable to assume that a network administrator might > >> want to use a single tool for monitoring network device > >> configurations > >> in a topology, > >> and also assuming that devices other than standard PCs are > a part of > >> this topology, this proposal suggests that the idea behind managing > >> software > >> components should be "moved up" a level of abstraction. Using the > >> right type of abstraction would allow practically any type > of device > >> to be supported > >> in the management of software components, whether these > >> components be > >> "applications", an "operating system", or a "bios". > >> > >> A software component or "module" instance might be a suitable > >> level of > >> abstraction to allow non-PC devices to be managed in the > same way as > >> PC devices. > >> The software module abstraction would be a complex data type > >> that can > >> be multiply instanced. The complex data type would consist of (at > >> least) 3 pieces of information: > >> > >> - Module Type (This could be a value indicating OS, Bios, or > >> application, but might > >> not be required at all for remediation. > >> > >> - Module Vendor - The manufacturer of this particular > software module > >> > >> - Module Name - The name of the module such as "Mac OS X", or > >> "Windows Vista Ultimate" > >> > >> - Module Version - This could either be a version number, > >> build number, > >> build date and time, or whatever > >> the vendor uses to > >> identify unique versions. > >> > >> The "module" idea can be either evolved as is, or used to stimulate > >> discussion for > >> an appropriate level of abstraction to represent individual, > >> updateable software > >> components within a device. > >> > >> The rationale behind supporting non-PC devices is not > >> theoretical, in > >> that there is a "spectrum" of network-connected devices that exist > >> today. > >> The spectrum originating with devices that utilize only a single, > >> monolithic software load module, and end with devices that > >> could have > >> tertiary > >> or that utilize a single, monolithic software load, through devices > >> that support a tertiary structure (like PCs), to devices that > >> utilize a quarternary or even larger number of unique software > >> components. > >> > >> Using the "module" paradigm would allow all of these architectural > >> permutations > >> to exist simultaneously, and be managed (and remedied) > using similar > >> methods. > >> > >> This is just a first stab at an abstraction that might > encompass all > >> classes of > >> devices that wish to utilize the NEA protocols. It is likely that > >> other information > >> may be required of this attribute model. > >> > >> An example of a monolithic device module would consist of a single- > >> instance > >> of the module data type: > >> (Type="System",Vendor="HP", Name="HP Laserjet > >> System",Version="5J2-R2") > >> > >> A typical PC would consist of a multiply-instanced attribute or > >> attributes: > >> > >> (Type="BIOS", Vendor="Phoenix", Name="Phoenix DCore BIOS", > >> Version-"7R2") > >> (Type="OS", Vendor="Microsoft", Name="Windows Vista Ultimate", > >> Version="SP1") > >> (Type="APP", Vendor="Symantec", Name="AntiVirus", Version="3.2R2") > >> (Type="APP", Vendor="Microsoft", Name="IE", Version="7.3") > >> (Type="APP", Vendor="Symantec", Name="Firewall", Version="4.3") > >> (Type="CFG", Vendor="Symantec", Name="fwrules", Version="16") > >> > >> Using the "module" abstraction would even allow the creation, and > >> subsequent management/remediation of individual, updateable > >> components > >> like firewall > >> rulesets, which could be updated without necessarily updating the > >> application > >> itself. NOTE: the "CFG" module type as illustrated above. > >> > >> > >> _______________________________________________ > >> Nea mailing list > >> Nea@ietf.org > >> https://www.ietf.org/mailman/listinfo/nea > >> > > > > _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Sep 19 13:55:04 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26AB73A6B28; Fri, 19 Sep 2008 13:55:04 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC563A6B28 for ; Fri, 19 Sep 2008 13:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+Yy2gCiRuQv for ; Fri, 19 Sep 2008 13:55:01 -0700 (PDT) Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id 96AE73A6945 for ; Fri, 19 Sep 2008 13:55:01 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob60.postini.com ([64.18.6.12]) with SMTP; Fri, 19 Sep 2008 13:55:11 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Sep 2008 13:55:15 -0700 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Sep 2008 13:55:15 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Sep 2008 16:55:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Sep 2008 16:55:14 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus check on attributes suggested by Randy Turner Thread-Index: AckHwHUFLYCGK1h0ScqWMBGqiy0GlAHwvDzAAAFhYpACwk9qsA== References: <14181E32-7B3D-4DA3-85BB-21394865D6B9@amalfisystems.com> <9C033AD2-2BE7-4AA9-BAF7-B43991D53CE8@amalfisystems.com> <4A6D7DA5-193A-4FF4-AA3B-70E0304A1025@amalfisystems.com> From: "Stephen Hanna" To: X-OriginalArrivalTime: 19 Sep 2008 20:55:14.0793 (UTC) FILETIME=[03CEA590:01C91A9A] Subject: [Nea] Consensus check on attributes suggested by Randy Turner X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org I have not seen any more dialog on the attributes that Randy Turner proposed. The PA-TNC editors need to prepare the next version of that draft and I think that we had pretty much reached consensus on how to handle these attributes so I propose a resolution below. I invite NEA participants to indicate whether you agree with this resolution. Please respond within one week (by Friday, September 26). If there is WG consensus in favor of this resolution, the editors will put it into the next PA-TNC draft. Thanks, Steve Forwarding Enabled ------------------ Most fixed-function endpoints can easily determine whether they are forwarding traffic between interfaces. Extensible endpoints may not be sure if they have multiple interfaces since application software can forward traffic. There is some security value in determining this value since it may indicate that a device which should not be forwarding traffic is doing so. Therefore, an IETF Standard PA-TNC Attribute Type will be defined, named "Forwarding Enabled". The Attribute Value for this attribute will be a single octet with one of three values: 0 ("Disabled") if the endpoint is not forwarding traffic between network interfaces, 1 ("Enabled") if the endpoint is forwarding traffic between network interfaces, and 2 ("Unknown") if it is not known whether the endpoint is forwarding traffic between network interfaces. Secure Time Enabled ------------------- This attribute is complex and we have not yet seen a proposal for it so we will not standardize it yet. It can come later, maybe using our process for defining new IETF Standard PA-TNC Attribute Types. Minimum Cipher Suite -------------------- We did not reach consensus in favor of standardizing this attribute. Configuration State ------------------- We did not reach consensus in favor of standardizing this attribute. PSTN_Fax_Enabled ---------------- This attribute is mainly for hard copy devices so it will be defined by the Printer Working Group . Factory Default Password Enabled -------------------------------- Many embedded devices include a default static password for administration. If this password is not changed before the device is placed in service, it's often easy to compromise the device. Therefore, it's desirable to identify devices that still have a factory default password enabled via NEA. A new PA-TNC attribute named "Factory Default Password Enabled" should be defined. The Attribute Value for this attribute will be a single octet with a value of 0 if the endpoint does not have a factory default password enabled and 1 if the endpoint does have such a password enabled. _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Sep 19 14:02:33 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C443A6945; Fri, 19 Sep 2008 14:02:33 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831553A6945 for ; Fri, 19 Sep 2008 14:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIspzmdBxaQR for ; Fri, 19 Sep 2008 14:02:31 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by core3.amsl.com (Postfix) with ESMTP id 47F1E3A68FC for ; Fri, 19 Sep 2008 14:02:31 -0700 (PDT) Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m8JL2kTb013397 for ; Fri, 19 Sep 2008 17:02:46 -0400 Received: (qmail 8508 invoked by uid 78); 19 Sep 2008 21:02:14 -0000 Received: from unknown (HELO 129.sub-75-214-143.myvzw.com) (rturner@amalfisystems.com@75.214.143.129) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 19 Sep 2008 21:02:14 -0000 Message-Id: From: Randy Turner To: "Stephen Hanna" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 19 Sep 2008 14:01:51 -0700 References: <14181E32-7B3D-4DA3-85BB-21394865D6B9@amalfisystems.com> <9C033AD2-2BE7-4AA9-BAF7-B43991D53CE8@amalfisystems.com> <4A6D7DA5-193A-4FF4-AA3B-70E0304A1025@amalfisystems.com> X-Mailer: Apple Mail (2.929.2) Cc: nea@ietf.org Subject: Re: [Nea] Consensus check on attributes suggested by Randy Turner X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0368753205==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org --===============0368753205== Content-Type: multipart/signed; boundary=Apple-Mail-7-885259904; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-7-885259904 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Steve, Thanks for the "level-set" email... Your last email comments on the proposal indicated that we had "basic agreement" on the inclusion of the "Forwarding Enabled/Disabled" attribute as well. Can we include this in your "proposed consensus" ? Thanks! Randy On Sep 19, 2008, at 1:55 PM, Stephen Hanna wrote: > I have not seen any more dialog on the attributes that > Randy Turner proposed. The PA-TNC editors need to prepare > the next version of that draft and I think that we had pretty > much reached consensus on how to handle these attributes > so I propose a resolution below. I invite NEA participants > to indicate whether you agree with this resolution. Please > respond within one week (by Friday, September 26). If there > is WG consensus in favor of this resolution, the editors > will put it into the next PA-TNC draft. > > Thanks, > > Steve > > Forwarding Enabled > ------------------ > Most fixed-function endpoints can easily determine whether > they are forwarding traffic between interfaces. Extensible > endpoints may not be sure if they have multiple interfaces > since application software can forward traffic. There is > some security value in determining this value since it may > indicate that a device which should not be forwarding traffic > is doing so. Therefore, an IETF Standard PA-TNC Attribute Type > will be defined, named "Forwarding Enabled". The Attribute Value > for this attribute will be a single octet with one of three values: > 0 ("Disabled") if the endpoint is not forwarding traffic > between network interfaces, 1 ("Enabled") if the endpoint > is forwarding traffic between network interfaces, and 2 > ("Unknown") if it is not known whether the endpoint is > forwarding traffic between network interfaces. > > Secure Time Enabled > ------------------- > This attribute is complex and we have not yet seen a proposal > for it so we will not standardize it yet. It can come later, > maybe using our process for defining new IETF Standard PA-TNC > Attribute Types. > > Minimum Cipher Suite > -------------------- > We did not reach consensus in favor of standardizing this > attribute. > > Configuration State > ------------------- > We did not reach consensus in favor of standardizing this > attribute. > > PSTN_Fax_Enabled > ---------------- > This attribute is mainly for hard copy devices so it will > be defined by the Printer Working Group . > > Factory Default Password Enabled > -------------------------------- > Many embedded devices include a default static password > for administration. If this password is not changed before > the device is placed in service, it's often easy to compromise > the device. Therefore, it's desirable to identify devices > that still have a factory default password enabled via NEA. > A new PA-TNC attribute named "Factory Default Password Enabled" > should be defined. The Attribute Value for this attribute > will be a single octet with a value of 0 if the endpoint > does not have a factory default password enabled and 1 if > the endpoint does have such a password enabled. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > --Apple-Mail-7-885259904 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGMzCCAuww ggJVoAMCAQICEFcOr//jUHkfUhTpkkg2ZOgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDcxNDAzNDIwMVoXDTA5MDcxNDAzNDIw MVowSzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEoMCYGCSqGSIb3DQEJARYZcnR1 cm5lckBhbWFsZmlzeXN0ZW1zLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMRP PdzSr6DBCtVR07ig3LZ7rlDRh4scX9NVPMooYTipX05CwFS/Zy7Cz96TCRfo0oNzIDaEuwyixIoj SQR7viToR8z8NXodL8cWOFThHturmbRzpdOsiVSsI9xDY0ut48gShRhOiDqh2oF/mcbN2hfygIfw 3KFiXO+38Iud/lZhMJa1PADry4aiigsss1iy50/yd8BcDFQTNCw2HGprtHDJznuwZlfxS9manJt0 /TQfi5zSG9+45m1MDaJp9d1dRdGvyAGwuOqdzQ/27pZqsEH/6OavdQ5FsL2i2e36VbMryBucmn/L BCwSfovQ1pQHorO+pphYJapjImTZVB0ZtsUCAwEAAaM2MDQwJAYDVR0RBB0wG4EZcnR1cm5lckBh bWFsZmlzeXN0ZW1zLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE0GLbM/YIk1 PgOw2J+pzA89C0xGPlmsouUdSzE1m0oEpe0tFHtb51xRU8uHVRLkRaiALHmegKNptYVJbMNy2j37 Zy5pmog/qciiEiBOVUX9X8fckTapueK7SI03s4QRvKGXD8W9WspF1L8vjCdL1JOCq6PTE1NFgf0s 0B7oVluSMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBXDq//41B5H1IU6ZJI NmToMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA4MDkxOTIxMDE1MlowIwYJKoZIhvcNAQkEMRYEFBukH38iviZDSKQiugOKY6R5WXUjMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVw6v/+NQeR9SFOmSSDZk6DCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVw6v/+NQeR9SFOmSSDZk6DANBgkqhkiG9w0BAQEF AASCAQBYqBfIFXG7NmizvC8ySXKSV4Gi5HVtq64x2rDUsljrb4Hc1d2+b2qBZGbynXYzkpk/ojEm gHb11RyIhzUebCvwAYN7QIPHY12XCewsOhlCDwm/RQtxmtijT9oArNokSWofI9QuWMhwcXyLlHIf Ce8nFxp7bW/Wpu8VbWPhqzVJJbYvP6WnjL67fSX1i0c5rkNZBqQTqQDxlEerTKUra4xB254DQ7L7 wz1vcjpZ7SzaUsTfGpXL7QnNbNWCfvzkFvgWs4jpM/i0IAWb06F3v/i6oeb1n39MfAWzBks1rGlF PQ1V3l7+qCVfiSFewVeAjdQTL/9ZWWwYas1N/wRabFcyAAAAAAAA --Apple-Mail-7-885259904-- --===============0368753205== 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://www.ietf.org/mailman/listinfo/nea --===============0368753205==-- From nea-bounces@ietf.org Fri Sep 19 17:34:44 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB273A688B; Fri, 19 Sep 2008 17:34:44 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A473A6962 for ; Fri, 19 Sep 2008 17:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq+ZEuMDLSNA for ; Fri, 19 Sep 2008 17:34:42 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id A979B3A6851 for ; Fri, 19 Sep 2008 17:34:39 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Fri, 19 Sep 2008 17:34:18 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Sep 2008 17:34:42 -0700 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Sep 2008 17:34:42 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Sep 2008 20:34:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Sep 2008 20:34:40 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Consensus check on attributes suggested by Randy Turner Thread-Index: AckamxJuIVeAMO2DTD2xA3Nsp0vMzAAAC7tA References: <14181E32-7B3D-4DA3-85BB-21394865D6B9@amalfisystems.com> <9C033AD2-2BE7-4AA9-BAF7-B43991D53CE8@amalfisystems.com> <4A6D7DA5-193A-4FF4-AA3B-70E0304A1025@amalfisystems.com> From: "Stephen Hanna" To: "Randy Turner" X-OriginalArrivalTime: 20 Sep 2008 00:34:41.0084 (UTC) FILETIME=[AB8737C0:01C91AB8] Cc: nea@ietf.org Subject: Re: [Nea] Consensus check on attributes suggested by Randy Turner X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Actually, that attribute IS included in my proposal. It's the first attribute that I listed (aptly named "Forwarding Enabled"). Did you miss it or are you unhappy with my proposal for what we should standardize? Thanks, Steve > -----Original Message----- > From: Randy Turner [mailto:rturner@amalfisystems.com] > Sent: Friday, September 19, 2008 5:02 PM > To: Stephen Hanna > Cc: nea@ietf.org > Subject: Re: [Nea] Consensus check on attributes suggested by > Randy Turner > > > Hi Steve, > > Thanks for the "level-set" email... > > Your last email comments on the proposal indicated that we > had "basic > agreement" on > the inclusion of the "Forwarding Enabled/Disabled" attribute as > well. Can we include > this in your "proposed consensus" ? > > Thanks! > Randy > > > On Sep 19, 2008, at 1:55 PM, Stephen Hanna wrote: > > > I have not seen any more dialog on the attributes that > > Randy Turner proposed. The PA-TNC editors need to prepare > > the next version of that draft and I think that we had pretty > > much reached consensus on how to handle these attributes > > so I propose a resolution below. I invite NEA participants > > to indicate whether you agree with this resolution. Please > > respond within one week (by Friday, September 26). If there > > is WG consensus in favor of this resolution, the editors > > will put it into the next PA-TNC draft. > > > > Thanks, > > > > Steve > > > > Forwarding Enabled > > ------------------ > > Most fixed-function endpoints can easily determine whether > > they are forwarding traffic between interfaces. Extensible > > endpoints may not be sure if they have multiple interfaces > > since application software can forward traffic. There is > > some security value in determining this value since it may > > indicate that a device which should not be forwarding traffic > > is doing so. Therefore, an IETF Standard PA-TNC Attribute Type > > will be defined, named "Forwarding Enabled". The Attribute Value > > for this attribute will be a single octet with one of three values: > > 0 ("Disabled") if the endpoint is not forwarding traffic > > between network interfaces, 1 ("Enabled") if the endpoint > > is forwarding traffic between network interfaces, and 2 > > ("Unknown") if it is not known whether the endpoint is > > forwarding traffic between network interfaces. > > > > Secure Time Enabled > > ------------------- > > This attribute is complex and we have not yet seen a proposal > > for it so we will not standardize it yet. It can come later, > > maybe using our process for defining new IETF Standard PA-TNC > > Attribute Types. > > > > Minimum Cipher Suite > > -------------------- > > We did not reach consensus in favor of standardizing this > > attribute. > > > > Configuration State > > ------------------- > > We did not reach consensus in favor of standardizing this > > attribute. > > > > PSTN_Fax_Enabled > > ---------------- > > This attribute is mainly for hard copy devices so it will > > be defined by the Printer Working Group . > > > > Factory Default Password Enabled > > -------------------------------- > > Many embedded devices include a default static password > > for administration. If this password is not changed before > > the device is placed in service, it's often easy to compromise > > the device. Therefore, it's desirable to identify devices > > that still have a factory default password enabled via NEA. > > A new PA-TNC attribute named "Factory Default Password Enabled" > > should be defined. The Attribute Value for this attribute > > will be a single octet with a value of 0 if the endpoint > > does not have a factory default password enabled and 1 if > > the endpoint does have such a password enabled. > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www.ietf.org/mailman/listinfo/nea > > > > _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Sep 19 17:51:51 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140F13A6851; Fri, 19 Sep 2008 17:51:51 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFE13A6851 for ; Fri, 19 Sep 2008 17:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXQyhBaebn1o for ; Fri, 19 Sep 2008 17:51:42 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by core3.amsl.com (Postfix) with ESMTP id 562D53A67AA for ; Fri, 19 Sep 2008 17:51:42 -0700 (PDT) Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m8K0pv4m006369 for ; Fri, 19 Sep 2008 20:51:57 -0400 Received: (qmail 23798 invoked by uid 78); 20 Sep 2008 00:51:57 -0000 Received: from unknown (HELO ?10.0.1.97?) (71.119.122.114) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 20 Sep 2008 00:51:57 -0000 Message-Id: <16C9AA5F-64EE-496E-808A-B45546BDDE5C@amalfisystems.com> From: Randy Turner To: Stephen Hanna In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 19 Sep 2008 17:51:56 -0700 References: <14181E32-7B3D-4DA3-85BB-21394865D6B9@amalfisystems.com> <9C033AD2-2BE7-4AA9-BAF7-B43991D53CE8@amalfisystems.com> <4A6D7DA5-193A-4FF4-AA3B-70E0304A1025@amalfisystems.com> X-Mailer: Apple Mail (2.929.2) Cc: nea@ietf.org Subject: Re: [Nea] Consensus check on attributes suggested by Randy Turner X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Hi Steve, Yes you are correct, I must have blown right past that in your previous email.... Sorry for the wasted list bandwidth :) So it would seem we have consensus on "Forwarding-Enabled" and "Factory Default Password Enabled" I'm ok with this...given that we have a schedule we would like to keep and some of the other items will take much more discussion and or mulling... Thanks again! Randy On Sep 19, 2008, at 5:34 PM, Stephen Hanna wrote: > Actually, that attribute IS included in my proposal. > It's the first attribute that I listed (aptly named > "Forwarding Enabled"). Did you miss it or are you > unhappy with my proposal for what we should standardize? > > Thanks, > > Steve > >> -----Original Message----- >> From: Randy Turner [mailto:rturner@amalfisystems.com] >> Sent: Friday, September 19, 2008 5:02 PM >> To: Stephen Hanna >> Cc: nea@ietf.org >> Subject: Re: [Nea] Consensus check on attributes suggested by >> Randy Turner >> >> >> Hi Steve, >> >> Thanks for the "level-set" email... >> >> Your last email comments on the proposal indicated that we >> had "basic >> agreement" on >> the inclusion of the "Forwarding Enabled/Disabled" attribute as >> well. Can we include >> this in your "proposed consensus" ? >> >> Thanks! >> Randy >> >> >> On Sep 19, 2008, at 1:55 PM, Stephen Hanna wrote: >> >>> I have not seen any more dialog on the attributes that >>> Randy Turner proposed. The PA-TNC editors need to prepare >>> the next version of that draft and I think that we had pretty >>> much reached consensus on how to handle these attributes >>> so I propose a resolution below. I invite NEA participants >>> to indicate whether you agree with this resolution. Please >>> respond within one week (by Friday, September 26). If there >>> is WG consensus in favor of this resolution, the editors >>> will put it into the next PA-TNC draft. >>> >>> Thanks, >>> >>> Steve >>> >>> Forwarding Enabled >>> ------------------ >>> Most fixed-function endpoints can easily determine whether >>> they are forwarding traffic between interfaces. Extensible >>> endpoints may not be sure if they have multiple interfaces >>> since application software can forward traffic. There is >>> some security value in determining this value since it may >>> indicate that a device which should not be forwarding traffic >>> is doing so. Therefore, an IETF Standard PA-TNC Attribute Type >>> will be defined, named "Forwarding Enabled". The Attribute Value >>> for this attribute will be a single octet with one of three values: >>> 0 ("Disabled") if the endpoint is not forwarding traffic >>> between network interfaces, 1 ("Enabled") if the endpoint >>> is forwarding traffic between network interfaces, and 2 >>> ("Unknown") if it is not known whether the endpoint is >>> forwarding traffic between network interfaces. >>> >>> Secure Time Enabled >>> ------------------- >>> This attribute is complex and we have not yet seen a proposal >>> for it so we will not standardize it yet. It can come later, >>> maybe using our process for defining new IETF Standard PA-TNC >>> Attribute Types. >>> >>> Minimum Cipher Suite >>> -------------------- >>> We did not reach consensus in favor of standardizing this >>> attribute. >>> >>> Configuration State >>> ------------------- >>> We did not reach consensus in favor of standardizing this >>> attribute. >>> >>> PSTN_Fax_Enabled >>> ---------------- >>> This attribute is mainly for hard copy devices so it will >>> be defined by the Printer Working Group . >>> >>> Factory Default Password Enabled >>> -------------------------------- >>> Many embedded devices include a default static password >>> for administration. If this password is not changed before >>> the device is placed in service, it's often easy to compromise >>> the device. Therefore, it's desirable to identify devices >>> that still have a factory default password enabled via NEA. >>> A new PA-TNC attribute named "Factory Default Password Enabled" >>> should be defined. The Attribute Value for this attribute >>> will be a single octet with a value of 0 if the endpoint >>> does not have a factory default password enabled and 1 if >>> the endpoint does have such a password enabled. >>> _______________________________________________ >>> Nea mailing list >>> Nea@ietf.org >>> https://www.ietf.org/mailman/listinfo/nea >>> >> >> > _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Sep 22 12:32:10 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6633A6B86; Mon, 22 Sep 2008 12:32:10 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E3D3A6BA4 for ; Mon, 22 Sep 2008 12:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pc8Eyw8XtvaX for ; Mon, 22 Sep 2008 12:32:01 -0700 (PDT) Received: from extu-mxob-2.symantec.com (extu-mxob-2.symantec.com [216.10.194.135]) by core3.amsl.com (Postfix) with ESMTP id 5645F3A6BAF for ; Mon, 22 Sep 2008 12:32:01 -0700 (PDT) Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by extu-mxob-2.symantec.com (8.14.1/8.14.1) with ESMTP id m8MIpAFg006543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 11:51:10 -0700 Received: from reserved-155-64-230-18.ges.symantec.com ([155.64.230.18] helo=TUS1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1KhqV4-0003kQ-Mi; Mon, 22 Sep 2008 11:51:10 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Sep 2008 11:51:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Sep 2008 11:50:51 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] [NEA] Proposals for Attribute Categories & Attributes Thread-Index: AckJ4BGjV8h/k4IGEkiSG8khx24ZGgTAjf5Q References: From: "Paul Sangster" To: "Brian Ford" , "NEA" X-OriginalArrivalTime: 22 Sep 2008 18:51:10.0644 (UTC) FILETIME=[2DFCE740:01C91CE4] Subject: Re: [Nea] [NEA] Proposals for Attribute Categories & Attributes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1540712592==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1540712592== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C91CE4.23A1E50B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C91CE4.23A1E50B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, =20 Sorry for the delay but the editor team would like to get back to you on the suggestion below. We think you have an interesting idea of allowing the NEA Server to obtain more detailed information about the NEA Client (including vendor information and version). We believe the best way to do this consistent with RFC 5209 is to add a PA subtype (AKA component type) for the NEA Client. This will allow the NEA Server to obtain a good amount of information about the NEA Client so could be factored into a policy decision. We plan to add this in the next revision unless the WG doesn't feel this is necessary) and believe this could cover your QR and AG models (QR if parts of the NEA Client are built into the OS). =20 As for the probe (PR) and passive probe (PP) models, these involce components outside the scope of the NEA WG charter and what is defined in RFC 5209. If/when our charter is expanded down the road we could reconsider this decision. =20 Paul ________________________________ From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Brian Ford Sent: Friday, August 29, 2008 7:04 AM To: NEA Subject: Re: [Nea] [NEA] Proposals for Attribute Categories & Attributes =09 =09 NEA Community, =09 I suggest that an important Attribute Category would be "Assessment Method". This category would include information about how the endpoint was assessed (method) and be able to be correlated to the time of assessment . =20 =09 When I think about posture attributes I believe that there are a number of methods that a policy decision point (PDP) can expect the attributes to have been collected. =20 =09 #1 - The operating system on an endpoint reports its attributes. I refer to this as Query-Response [QR] case. #2 - Some software added to the endpoint determines and reports attributes. I call this the Agent [AG] case. #3 - Some other device on the network interacts with an endpoint and reports attributes. This is a Probe [PR] case. #4 - Some other device on the network does not interact with an endpoint and reports its attributes. I refer to this as a Passive Probe [PP]. There might be other cases... =09 I would suggest that these four (and perhaps other) collection models might be attributes make up an category called Assessment Method. =09 I think it would be valuable if the PDP could make a decision knowing the answers for up to all four of these methods for a single endpoint. For example a PC (Endpoint X) might have an agent installed that provided data (#2) AND that same PC was probed when it was detected on the network (#3). Another example might be a network print server (Endpoint Y) that reported attributes (#1) AND was subjected to a passive probe (#4).=20 =09 When data arrives at the PDP it could be visualized as a stream: =09 [ENDPOINT X MAC ADDR], [TIME A], [ASSESSMENT METHOD AG], [DATA SET 1],... [DATA SET N] [ENDPOINT Y MAC ADDR], [TIME A+1], [ASSESSMENT METHOD QR], [DATA SET 1],... [DATA SET N] [ENDPOINT X MAC ADDR], [TIME A+2], [ASSESSMENT METHOD PR], [DATA SET 1],... [DATA SET N] [ENDPOINT Y MAC ADDR], [TIME A+3], [ASSESSMENT METHOD PP], [DATA SET 1],... [DATA SET N] =09 The PDP could then build and (temporarily) maintain a data structure about Endpoint X and Endpoint Y that has information available about all the endpoints it knows about. =20 =09 [ENDPOINT X MAC ADDR], [DATA GATHERED AT TIME A], DATA GATHERED AT TIME A+2] =20 =09 The PDP could then make decisions based on any data in that data structure that meets it's "freshness" requirements (aging out old data) or if no data meets those requirements it could call for (as an example) an active probe [PR] or query the agent [AG]. =09 Note: Writing this data stream described above off to a storage device also creates a potentially valuable data store. Later processing of this data could be used to create a sort of "batting average" that would report on the accuracy of the different assessment methods and how well the PDP rules are working. =09 Liberty, =09 Brian =09 =09 ------_=_NextPart_001_01C91CE4.23A1E50B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [NEA] Proposals for Attribute Categories & = Attributes
Brian,
 
Sorry for the delay but the editor team would = like to get=20 back to you on the suggestion below.  We think you have an = interesting idea=20 of allowing the NEA Server to obtain more detailed information about the = NEA=20 Client (including vendor information and version).  We believe the = best way=20 to do this consistent with RFC 5209 is to add a PA subtype (AKA = component type)=20 for the NEA Client.  This will allow the NEA Server to obtain a = good amount=20 of information about the NEA Client so could be factored into a = policy=20 decision. We plan to add this in the next revision unless the = WG=20 doesn't feel this is necessary) and believe this could cover your = QR and AG=20 models (QR if parts of the NEA Client are built into the=20 OS).
 
As for the probe (PR) and passive probe (PP)=20 models, these involce components outside the scope of the NEA = WG=20 charter and what is defined in RFC 5209.  If/when our charter=20 is expanded down the road we could reconsider this = decision.
 
Paul

From: nea-bounces@ietf.org=20 [mailto:nea-bounces@ietf.org] On Behalf Of Brian = Ford
Sent:=20 Friday, August 29, 2008 7:04 AM
To: NEA
Subject: = Re: [Nea]=20 [NEA] Proposals for Attribute Categories & = Attributes

NEA Community,

I suggest that an = important=20 Attribute Category would be “Assessment Method”. =  This category would=20 include information about how the endpoint was assessed (method) and = be able=20 to be correlated to the time of assessment .  

When I = think about=20 posture attributes I believe that there are a number of methods that a = policy=20 decision point (PDP) can expect the attributes to have been collected. =  

#1 – The operating system on an endpoint reports = its attributes.=20   I refer to this as Query-Response [QR] case.
#2 – = Some software=20 added to the endpoint determines and reports attributes.  I call = this the=20 Agent [AG] case.
#3 – Some other device on the network = interacts with an=20 endpoint and reports attributes. This is a Probe [PR] case.
#4 = – Some other=20 device on the network does not interact with an endpoint and reports = its=20 attributes. I refer to this as a Passive Probe [PP].
There might be = other=20 cases...

I would suggest that these four (and perhaps other) = collection=20 models might be attributes make up an category called Assessment=20 Method.

I think it would be valuable if the PDP could make a = decision=20 knowing the answers for up to all four of these methods for a single = endpoint.=20 For example a PC (Endpoint X) might have an agent installed that = provided data=20 (#2) AND that same PC was probed when it was detected on the network = (#3).=20  Another example might be a network print server (Endpoint Y) = that=20 reported attributes (#1) AND was subjected to a passive probe (#4).=20

When data arrives at the PDP it could be visualized as a=20 stream:

[ENDPOINT X MAC ADDR], [TIME A], [ASSESSMENT METHOD = AG], [DATA=20 SET 1],... [DATA SET N]
[ENDPOINT Y MAC ADDR], [TIME A+1], = [ASSESSMENT=20 METHOD QR], [DATA SET 1],... [DATA SET N]
[ENDPOINT X MAC ADDR], = [TIME=20 A+2], [ASSESSMENT METHOD PR], [DATA SET 1],... [DATA SET = N]
[ENDPOINT Y MAC=20 ADDR], [TIME A+3], [ASSESSMENT METHOD PP], [DATA SET 1],... [DATA SET=20 N]

The PDP could then build and (temporarily) maintain a data = structure=20 about Endpoint X and Endpoint Y that has information available about = all the=20 endpoints it knows about.  

[ENDPOINT X MAC ADDR], [DATA = GATHERED=20 AT TIME A], DATA GATHERED AT TIME A+2]  

The PDP could = then make=20 decisions based on any data in that data structure that meets = it’s “freshness”=20 requirements (aging out old data) or if no data meets those = requirements it=20 could call for (as an example) an active probe [PR] or query the agent = [AG].

Note: Writing this data stream described above off to a = storage=20 device also creates a potentially valuable data store.  Later = processing=20 of this data could be used to create a sort of “batting = average” that would=20 report on the accuracy of the different assessment methods and how = well the=20 PDP rules are=20 working.

Liberty,

Brian

<= /BODY> ------_=_NextPart_001_01C91CE4.23A1E50B-- --===============1540712592== 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://www.ietf.org/mailman/listinfo/nea --===============1540712592==-- From nea-bounces@ietf.org Mon Sep 22 13:32:04 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7113A6AF0; Mon, 22 Sep 2008 13:32:04 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5457D3A67D2 for ; Mon, 22 Sep 2008 13:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idhzKUfw8ad8 for ; Mon, 22 Sep 2008 13:31:56 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by core3.amsl.com (Postfix) with ESMTP id 395CC3A6B05 for ; Mon, 22 Sep 2008 13:31:56 -0700 (PDT) Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m8MKVnWu021436 for ; Mon, 22 Sep 2008 16:31:51 -0400 Received: (qmail 7120 invoked by uid 78); 22 Sep 2008 20:31:48 -0000 Received: from unknown (HELO 5.sub-75-217-243.myvzw.com) (rturner@amalfisystems.com@75.217.243.5) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 22 Sep 2008 20:31:48 -0000 Message-Id: <4743E70B-7B5B-40C9-A16F-FC59D36C6DF3@amalfisystems.com> From: Randy Turner To: Paul Sangster In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 13:31:31 -0700 References: X-Mailer: Apple Mail (2.929.2) Cc: NEA Subject: [Nea] Endpoint vs. device X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1641187295==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org --===============1641187295== Content-Type: multipart/signed; boundary=Apple-Mail-2--1004843895; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-2--1004843895 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi All, I was re-reading the "NEA Requirements" RFC and I think some guidance and or clarification needs to be provided for virtualized environments. The text in the requirements document (section 5.1.1 I believe) I think leaves too much open-ended. We use the term "device" attributes everywhere, but this gets confusing in a virtualized environment about the meaning of "device". At a minimum, we may need a "terminology" section that rigorously defines what we mean by device, given that we've said in the requirements section that we're only talking about NEA clients operating within the context of a "execution domain", and that anything that attempts to aggregate execution domains is "outside the scope of this specification". In the terminology section of the requirements doc we say "endpoint device", which, given the current language makes it more difficult to interpret in the context of virtualization. Maybe we should at least state that there is a one-to- many relationship between endpoints and devices. It's not clear that we can necessarily get away with as little language about virtualization as we have now...the rate of deployment of virtualized systems is exploding and it seems like we should address it more clearly, at least with some type of guidance about how policy decision points might be able to "infer" that endpoints are residing on the same device. If this is already addressed somewhere in the current doc set (beyond what I referenced above), I apologize in advance, but please let me know...I may have inadvertently missed it. Thanks! Randy --Apple-Mail-2--1004843895 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGMzCCAuww ggJVoAMCAQICEFcOr//jUHkfUhTpkkg2ZOgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDcxNDAzNDIwMVoXDTA5MDcxNDAzNDIw MVowSzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEoMCYGCSqGSIb3DQEJARYZcnR1 cm5lckBhbWFsZmlzeXN0ZW1zLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMRP PdzSr6DBCtVR07ig3LZ7rlDRh4scX9NVPMooYTipX05CwFS/Zy7Cz96TCRfo0oNzIDaEuwyixIoj SQR7viToR8z8NXodL8cWOFThHturmbRzpdOsiVSsI9xDY0ut48gShRhOiDqh2oF/mcbN2hfygIfw 3KFiXO+38Iud/lZhMJa1PADry4aiigsss1iy50/yd8BcDFQTNCw2HGprtHDJznuwZlfxS9manJt0 /TQfi5zSG9+45m1MDaJp9d1dRdGvyAGwuOqdzQ/27pZqsEH/6OavdQ5FsL2i2e36VbMryBucmn/L BCwSfovQ1pQHorO+pphYJapjImTZVB0ZtsUCAwEAAaM2MDQwJAYDVR0RBB0wG4EZcnR1cm5lckBh bWFsZmlzeXN0ZW1zLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE0GLbM/YIk1 PgOw2J+pzA89C0xGPlmsouUdSzE1m0oEpe0tFHtb51xRU8uHVRLkRaiALHmegKNptYVJbMNy2j37 Zy5pmog/qciiEiBOVUX9X8fckTapueK7SI03s4QRvKGXD8W9WspF1L8vjCdL1JOCq6PTE1NFgf0s 0B7oVluSMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBXDq//41B5H1IU6ZJI NmToMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA4MDkyMjIwMzEzMlowIwYJKoZIhvcNAQkEMRYEFDHrvmFE6VhCV2+FEwFtxDX+t89mMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVw6v/+NQeR9SFOmSSDZk6DCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVw6v/+NQeR9SFOmSSDZk6DANBgkqhkiG9w0BAQEF AASCAQCLsBVHqts0a0K+SY0IhuG531vt9R5hTDyZA5Q2emqnOqjE/ifUkbRFkbQor5dN2jW+z5ai q/B0Xyc6SFiOEaDWTPxj5bFC2uJbOiXaTmiJILTjyF3omY1NVDETCFUlmY9z5jxUc7OzEHAmrhz3 /+l+XktecOtjisvi+/afIY37rN5IUOOmGPZwqa2N9jXB9TaamTr1+kvMcHl8CWjE9WRyarTCOVbk hRdqYBEuf/UR0c0c4UJWa+qyVT+kXfN7kax8tOM+agBHeVHg9JrKW6uK3J0g+mW7RIc/XsYW+4J1 n74vj38th+ATu3SpRehZiN/701kgS5yVxzos4woCwM8qAAAAAAAA --Apple-Mail-2--1004843895-- --===============1641187295== 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://www.ietf.org/mailman/listinfo/nea --===============1641187295==-- From nea-bounces@ietf.org Tue Sep 23 07:44:53 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D682A3A69A9; Tue, 23 Sep 2008 07:44:53 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAECC3A69A9 for ; Tue, 23 Sep 2008 07:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AR3BVJg0Q7f for ; Tue, 23 Sep 2008 07:44:49 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id D84A83A67E5 for ; Tue, 23 Sep 2008 07:44:48 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Tue, 23 Sep 2008 07:44:35 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Sep 2008 07:44:37 -0700 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Sep 2008 07:44:37 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Sep 2008 10:44:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Sep 2008 10:44:35 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verifying NEA WG Consensus from Dublin Thread-Index: AckamdJDt+Cex9OwQ4a0dVExo/wAUwC8L9Jw From: "Stephen Hanna" To: X-OriginalArrivalTime: 23 Sep 2008 14:44:36.0797 (UTC) FILETIME=[E694BED0:01C91D8A] Subject: [Nea] Verifying NEA WG Consensus from Dublin X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org I'd like to verify WG consensus on a few items that were discussed at the NEA WG meeting at IETF 72. All of these seemed to have consensus among those who attended the meeting but I would like to verify that consensus on the NEA email list since only consensus on the email list is true WG consensus in the IETF. Therefore, please send email to the list to indicate if you agree with these items and, if not, which ones you disagree with and why. Please respond within two weeks (by October 7) so that the PA-TNC and PB-TNC editors can complete the next revisions of these drafts promptly. I will send out another email in a minute on a topic that did not seem to have consensus at the NEA meeting in Dublin: IANA Considerations. Thanks, Steve PB-TNC Changes -------------- Ravi Sahita proposed moving the PB-Batch-Type to the PB-TNC header. This is a 16 bit integer with enumerated values that indicate the type of the batch. It's currently carried in a PB-TNC message of type PB-Batch-Type but we require that there be one and only one such message in each batch so it seems that it would just be simpler and more efficient to move this field into the PB-TNC header. We already have 24 reserved bits in that header so there's no problem with making this change. When a full-duplex PT is being used, we'd like to allow either the NEA Client or NEA Server to request a retry at any time. Right now, PB-TNC is strictly half-duplex even if the PT is not and that tightly restricts when the NEA Client and NEA Server can request retries (only when it's their turn to send). That causes problems if one side detects a problem such as a change in policy or in endpoint configuration. They might have to wait a long time to be able to signal this problem and request a retry. In fact, they might have to wait indefinitely. This change is not a big one but it does modify the state machine to indicate that whenever SRETRY is allowed, CRETRY is also allowed and vice versa. A PB-TNC RESULT batch currently includes an Access-Recommendation that contains one of the values Access Allowed, Quarantined, or Access Denied. There's currently no way in PB-TNC to indicate whether the NEA Client was found to be compliant with policy. So we suggest adding posture assessment that could have values like Compliant, Non-Compliant, Non-Compliant Major Issue, Error, and Don't Know. PA-TNC Changes -------------- First, we propose changing how attribute correlation is handled. Currently, a Correlation ID is used to handle the case where a single Posture Collector is able to gather information on several products. This is somewhat unusual but it causes problems since that Posture Collector might send a single PA-TNC message with multiple Product Information, Numeric Version, and Operational Status attributes, for example. Which Product Information attribute goes with which Numeric Version Attribute? Today, we solve this problem by tagging the attributes with an optional Correlation ID. The proposed new solution to this problem is to have a Posture Collector that wants to report on several products use a different Posture Collector ID for each product that it reports on. This removes the need to have a special protocol feature to handle this case. Effectively, it pushes the tagging up the stack into PB where we already have a field that can be used to solve this problem. The main advantage is that it simplifies the protocol. The main disadvantage is that it complicates the Posture Broker Client and Posture Collector implementation if they want to handle this case since they need to handle "virtual" Posture Collector IDs. The second suggested change in PA-TNC is the addition of an Assessment Result attribute that would allow a Posture Validator to inform a Posture Collector about the compliance decision for a component, just like the similar proposal for PB-TNC above but specific to a component. The third suggested change in PA-TNC is the addition of a Remediation attribute that would allow a Posture Validator to send remediation instructions to a Posture Collector. This is a valuable feature since the Posture Collector is the best place to do automated remediation. _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Sep 23 08:34:53 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA5D3A6CEB; Tue, 23 Sep 2008 08:34:53 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C413A6CC0 for ; Tue, 23 Sep 2008 08:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmgmyZfcvSBj for ; Tue, 23 Sep 2008 08:34:47 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 5D7AC3A6CEC for ; Tue, 23 Sep 2008 08:34:16 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Tue, 23 Sep 2008 08:32:58 PDT Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Sep 2008 08:33:15 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Sep 2008 11:33:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Sep 2008 11:33:14 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA Considerations for NEA Protocols Thread-Index: AckcuO9U1RSxIYIqTW2xfCi8fHi5TQA0gq2A From: "Stephen Hanna" To: X-OriginalArrivalTime: 23 Sep 2008 15:33:14.0711 (UTC) FILETIME=[B1CB1670:01C91D91] Subject: [Nea] IANA Considerations for NEA Protocols X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org In the NEA WG meeting at IETF 72, we had lots of discussion about IANA considerations but we didn't reach consensus for any one approach. I'd like to raise this issue for discussion on the email list in hopes that we can discuss the pros and cons of various approaches and agree on one. I think the main question is: * What process should we use for adding new assigned numbers ("codepoints") to the IANA registries created by the NEA protocol specs? The registries in question (described in PB-TNC and PA-TNC) are: IETF Standard PB-TNC Message Types IETF Standard PB-TNC Remediation Parameters Types IETF Standard PB-TNC Error Codes IETF Standard PA Subtypes IETF Standard PA-TNC Attribute Types IETF Standard PA-TNC Error Codes The PB-TNC and PA-TNC drafts currently say that codepoints can be added to these registries only by IETF Consensus, as defined in RFC 2434. This would require an RFC approved by the IESG. Note that RFC 2434 has been obsoleted by RFC 5226 so that RFC is more relevant to our discussion now. During the discussion at IETF 72, it was suggested that requiring an RFC for each new codepoint will be too slow and cumbersome. People will instead just use the vendor-specific values allowed by the specs. The suggestion was to instead use Expert Review to decide on adding new codepoints to the registries. It was strongly suggested that we require that a specification for each codepoint be archived in a permanently accessible location. In fact, we had a quick straw poll on this question: Should we require some sort of permanent documentation in order to get an identifier from the vendor id 0 namespace? The result was unanimous agreement that we should. I suspect there may be consensus now on this proposition: To add assigned values ("codepoints") to the IANA registries created by the NEA specs, we should require Expert Review with a permanently archived Specification Required. Please consider this proposition and send email with any comments, including statements of support or non-support. BTW, I have consulted with IANA about how we can ensure that the "permanently archived" specifications for codepoints are actually permanently archived. IANA said that they can archive a spec and make it available from their site if needed. They will need to get permission from the copyright holder but they can do so. Another option would be to use the RFC series as our permanent archive but that involves a lot more process, delay, reformatting, and general overhead than just archiving a copy of the spec. One related topic that was discussed at the meeting was how to handle vendor-specific codepoints (vendor ID > 0) that become popular and widely implemented. Some people felt that it's best to create an IETF standard codepoint (vendor ID = 0) that corresponds to these codepoints and ask implementers to transition to the new codepoint. Others said that once a vendor-specific codepoint is widely implemented, it's unlikely that people will leave it. Doing so would cause pain and expense with little value. These folks seemed to suggest that we should allow vendors to document their vendor-specific codepoints to increase clarity and interoperability. It was not clear whether this documentation should be done via an Expert Review process with permanently archived Specification Required or via an Informational RFC or via some other mechanism. I'd like to invite discussion on this topic also. I hope that we can reach consensus on these two topics (how to approve Vendor 0 codepoints and how/whether to document vendor-specific codepoints) in the next two weeks so that our document editors can include the consensus in the next versions of the NEA specs. So please think about these topics and respond promptly. I will declare WG consensus once we seem to have reached it. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Sep 23 15:44:27 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9089428C26D; Tue, 23 Sep 2008 15:44:27 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7370B28C26D for ; Tue, 23 Sep 2008 15:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Rz6g4WiHeOb for ; Tue, 23 Sep 2008 15:44:25 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4CF9D28C266 for ; Tue, 23 Sep 2008 15:44:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,295,1220227200"; d="scan'208";a="21871484" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Sep 2008 22:44:29 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8NMiTsW023373 for ; Tue, 23 Sep 2008 18:44:29 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8NMiTC6003103 for ; Tue, 23 Sep 2008 22:44:29 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Sep 2008 18:44:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Sep 2008 18:42:59 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for a volunteer for due diligence effort on Posture attributes thread-index: AckdzbrfjJ29ebtURSiwlQhDtWgCPg== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 23 Sep 2008 22:44:28.0982 (UTC) FILETIME=[F00F8560:01C91DCD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=964; t=1222209869; x=1223073869; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20(sethomso)=22=20 |Subject:=20Call=20for=20a=20volunteer=20for=20due=20dilige nce=20effort=20on=20Posture=20attributes |Sender:=20 |To:=20; bh=fR6bvAa9r8MTT/116AIkpKj3fp3K4Eq9gPEEUmPIKM8=; b=JOjD8dNR2vgmTSEYZc+KJk7q8A3NQJY2/QDV9gs59fn1JOdEffDC1ZXjF7 uK/ZFC0MUTkuZJT/6S9FlB2StTZ6HggWYGRHLkjsCd3p9p7zzDbjFO2Xave0 648oUSmX+a; Authentication-Results: rtp-dkim-1; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Nea] Call for a volunteer for due diligence effort on Posture attributes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org At IETF 72, our AD, Tim Polk, encouraged the WG to put real effort into ensuring that the set of posture attributes is as complete as possible prior to standardization of the protocol I-Ds. Otherwise, the danger is that different vendors will implement their own version of a common attribute and it will be too late to create a standard version. One way to do this is to survey attributes supported in existing (and even past) products. Another source of input is looking at different types of endpoints, such as the recent input on the NEA mailing list from the Printer working group. Rather than imposing further on the editors of the protocol documents, we are requesting a volunteer who is willing to drive this due diligence effort. If you are interested, please contact Steve and me directly by Monday Sept 29. The goal is to have a first draft of the output of this effort for WG consideration prior to IETF 73. Thanks Susan and Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Sep 29 06:33:14 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9093A6A1D; Mon, 29 Sep 2008 06:33:14 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2EC3A6A0A for ; Mon, 29 Sep 2008 06:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UksmVEg48cdY for ; Mon, 29 Sep 2008 06:33:12 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 6B5173A69BA for ; Mon, 29 Sep 2008 06:33:11 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Mon, 29 Sep 2008 06:32:16 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 06:33:02 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 06:33:02 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 09:33:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Sep 2008 09:33:01 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Consensus check on attributes suggested by Randy Turner Thread-Index: AckHwHUFLYCGK1h0ScqWMBGqiy0GlAHwvDzAAAFhYpACwk9qsAHpJKIg References: <14181E32-7B3D-4DA3-85BB-21394865D6B9@amalfisystems.com><9C033AD2-2BE7-4AA9-BAF7-B43991D53CE8@amalfisystems.com><4A6D7DA5-193A-4FF4-AA3B-70E0304A1025@amalfisystems.com> From: "Stephen Hanna" To: X-OriginalArrivalTime: 29 Sep 2008 13:33:02.0225 (UTC) FILETIME=[E54B9010:01C92237] Subject: Re: [Nea] Consensus check on attributes suggested by Randy Turner X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org The one week comment period on this proposal has expired. The only comment that I received on this was from Randy Turner. He agreed with the proposed resolution. This does not represent a huge amount of support but nobody has voiced any concerns with the proposed resolution. Therefore, I will ask the editors of PA-TNC to reflect this resolution in the next revision of that document. There will be a full WG Last Call on that spec coming soon so that will provide another affirmation of support. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On > Behalf Of Stephen Hanna > Sent: Friday, September 19, 2008 4:55 PM > To: nea@ietf.org > Subject: [Nea] Consensus check on attributes suggested by Randy Turner > > I have not seen any more dialog on the attributes that > Randy Turner proposed. The PA-TNC editors need to prepare > the next version of that draft and I think that we had pretty > much reached consensus on how to handle these attributes > so I propose a resolution below. I invite NEA participants > to indicate whether you agree with this resolution. Please > respond within one week (by Friday, September 26). If there > is WG consensus in favor of this resolution, the editors > will put it into the next PA-TNC draft. > > Thanks, > > Steve > > Forwarding Enabled > ------------------ > Most fixed-function endpoints can easily determine whether > they are forwarding traffic between interfaces. Extensible > endpoints may not be sure if they have multiple interfaces > since application software can forward traffic. There is > some security value in determining this value since it may > indicate that a device which should not be forwarding traffic > is doing so. Therefore, an IETF Standard PA-TNC Attribute Type > will be defined, named "Forwarding Enabled". The Attribute Value > for this attribute will be a single octet with one of three values: > 0 ("Disabled") if the endpoint is not forwarding traffic > between network interfaces, 1 ("Enabled") if the endpoint > is forwarding traffic between network interfaces, and 2 > ("Unknown") if it is not known whether the endpoint is > forwarding traffic between network interfaces. > > Secure Time Enabled > ------------------- > This attribute is complex and we have not yet seen a proposal > for it so we will not standardize it yet. It can come later, > maybe using our process for defining new IETF Standard PA-TNC > Attribute Types. > > Minimum Cipher Suite > -------------------- > We did not reach consensus in favor of standardizing this > attribute. > > Configuration State > ------------------- > We did not reach consensus in favor of standardizing this > attribute. > > PSTN_Fax_Enabled > ---------------- > This attribute is mainly for hard copy devices so it will > be defined by the Printer Working Group . > > Factory Default Password Enabled > -------------------------------- > Many embedded devices include a default static password > for administration. If this password is not changed before > the device is placed in service, it's often easy to compromise > the device. Therefore, it's desirable to identify devices > that still have a factory default password enabled via NEA. > A new PA-TNC attribute named "Factory Default Password Enabled" > should be defined. The Attribute Value for this attribute > will be a single octet with a value of 0 if the endpoint > does not have a factory default password enabled and 1 if > the endpoint does have such a password enabled. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Sep 29 12:45:36 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A7028C110; Mon, 29 Sep 2008 12:45:36 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930C43A6B3A for ; Mon, 29 Sep 2008 12:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBwGLGdXdRKe for ; Mon, 29 Sep 2008 12:45:30 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 74C753A6ACC for ; Mon, 29 Sep 2008 12:45:29 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so363074qwe.31 for ; Mon, 29 Sep 2008 12:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=RBUZdoC3V1tODNXNX0mVGSTY+vsUHA7cB4xJ1hS7KG4=; b=a9jeG21mUaF1C6s0xaEYylgaMWjVEtaZkFJDqCCi+grSxs2Ta9Bf9N1BL/i3Cmf+LM siXz4U3Jbxj8UCVAK2PErueMTwuCstcFq7pqH3XzBLSa4F7OVQUBgJnF/I5pyVmUgc1m fnLuucb1RjN5vlZ+ZipEH8oO69XhIGWhLEXMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=YoS90dQaIJwCG9YW8lyYuTHO7ItCcJ8rGU//Ucb7w30pwnnTvGcSEBLkO4PlPtvFMR xBCjaMeo9VDBkpTMQXho9viuMKfN1eV7WuUKBLyJMyWPCNvUAFqhRzpxRW/1e/wufi/N bUM2ian9QfPJEMY344GAIcMR8rKLxSvRIYxwo= Received: by 10.214.46.10 with SMTP id t10mr4826985qat.80.1222717503858; Mon, 29 Sep 2008 12:45:03 -0700 (PDT) Received: from ?10.80.178.116? ([32.155.30.155]) by mx.google.com with ESMTPS id 8sm248169qwj.6.2008.09.29.12.45.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Sep 2008 12:45:03 -0700 (PDT) References: Message-Id: <48A0A41C-7549-48FA-A05A-5A19E51BAA77@gmail.com> From: Nea To: "nea@ietf.org" In-Reply-To: X-Mailer: iPhone Mail (5F136) Mime-Version: 1.0 (iPhone Mail 5F136) Date: Mon, 29 Sep 2008 12:44:47 -0700 Cc: "nea@ietf.org" Subject: Re: [Nea] Nea Digest, Vol 35, Issue 7 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org So it appears the only one we are including in the document us 'default password enabled' and that I can't really tell by the forwarded email if we have consensus. I do think including that is wise if we have consensus. I am hum with all the WG decisions on these. Sent from my mobile, please excuse any typos. On Sep 29, 2008, at 12:00 PM, nea-request@ietf.org wrote: > Send Nea mailing list submissions to > nea@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/nea > or, via email, send a message with subject or body 'help' to > nea-request@ietf.org > > You can reach the person managing the list at > nea-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nea digest..." > > > Today's Topics: > > 1. Re: Consensus check on attributes suggested by Randy Turner > (Stephen Hanna) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 29 Sep 2008 09:33:01 -0400 > From: "Stephen Hanna" > Subject: Re: [Nea] Consensus check on attributes suggested by Randy > Turner > To: > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > The one week comment period on this proposal has expired. > The only comment that I received on this was from Randy Turner. > He agreed with the proposed resolution. > > This does not represent a huge amount of support but nobody > has voiced any concerns with the proposed resolution. Therefore, > I will ask the editors of PA-TNC to reflect this resolution > in the next revision of that document. There will be a full > WG Last Call on that spec coming soon so that will provide > another affirmation of support. > > Thanks, > > Steve > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On >> Behalf Of Stephen Hanna >> Sent: Friday, September 19, 2008 4:55 PM >> To: nea@ietf.org >> Subject: [Nea] Consensus check on attributes suggested by Randy >> Turner >> >> I have not seen any more dialog on the attributes that >> Randy Turner proposed. The PA-TNC editors need to prepare >> the next version of that draft and I think that we had pretty >> much reached consensus on how to handle these attributes >> so I propose a resolution below. I invite NEA participants >> to indicate whether you agree with this resolution. Please >> respond within one week (by Friday, September 26). If there >> is WG consensus in favor of this resolution, the editors >> will put it into the next PA-TNC draft. >> >> Thanks, >> >> Steve >> >> Forwarding Enabled >> ------------------ >> Most fixed-function endpoints can easily determine whether >> they are forwarding traffic between interfaces. Extensible >> endpoints may not be sure if they have multiple interfaces >> since application software can forward traffic. There is >> some security value in determining this value since it may >> indicate that a device which should not be forwarding traffic >> is doing so. Therefore, an IETF Standard PA-TNC Attribute Type >> will be defined, named "Forwarding Enabled". The Attribute Value >> for this attribute will be a single octet with one of three values: >> 0 ("Disabled") if the endpoint is not forwarding traffic >> between network interfaces, 1 ("Enabled") if the endpoint >> is forwarding traffic between network interfaces, and 2 >> ("Unknown") if it is not known whether the endpoint is >> forwarding traffic between network interfaces. >> >> Secure Time Enabled >> ------------------- >> This attribute is complex and we have not yet seen a proposal >> for it so we will not standardize it yet. It can come later, >> maybe using our process for defining new IETF Standard PA-TNC >> Attribute Types. >> >> Minimum Cipher Suite >> -------------------- >> We did not reach consensus in favor of standardizing this >> attribute. >> >> Configuration State >> ------------------- >> We did not reach consensus in favor of standardizing this >> attribute. >> >> PSTN_Fax_Enabled >> ---------------- >> This attribute is mainly for hard copy devices so it will >> be defined by the Printer Working Group . >> >> Factory Default Password Enabled >> -------------------------------- >> Many embedded devices include a default static password >> for administration. If this password is not changed before >> the device is placed in service, it's often easy to compromise >> the device. Therefore, it's desirable to identify devices >> that still have a factory default password enabled via NEA. >> A new PA-TNC attribute named "Factory Default Password Enabled" >> should be defined. The Attribute Value for this attribute >> will be a single octet with a value of 0 if the endpoint >> does not have a factory default password enabled and 1 if >> the endpoint does have such a password enabled. >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea >> > > > ------------------------------ > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > > > End of Nea Digest, Vol 35, Issue 7 > ********************************** _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Sep 29 13:24:16 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFF33A6B71; Mon, 29 Sep 2008 13:24:16 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34413A68A4 for ; Mon, 29 Sep 2008 13:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6AwiRvoW14t for ; Mon, 29 Sep 2008 13:00:27 -0700 (PDT) Received: from smtp01.bis.na.blackberry.com (smtp01.bis.na.blackberry.com [216.9.248.48]) by core3.amsl.com (Postfix) with ESMTP id 55B753A6878 for ; Mon, 29 Sep 2008 13:00:26 -0700 (PDT) Received: from bxe014.bisx.prod.on.blackberry (bxe014.bisx.prod.on.blackberry [172.20.225.33]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id m8TJn9Q5023713 for nea@ietf.org; Mon, 29 Sep 2008 20:00:43 GMT X-rim-org-msg-ref-id: 1351216721 Message-ID: <1351216721-1222718443-cardhu_decombobulator_blackberry.rim.net-695467506-@bxe014.bisx.prod.on.blackberry> X-Priority: Normal References: <48A0A41C-7549-48FA-A05A-5A19E51BAA77@gmail.com> In-Reply-To: <48A0A41C-7549-48FA-A05A-5A19E51BAA77@gmail.com> Sensitivity: Normal Importance: Normal To: "nea@ietf.org" From: "Randy Turner" Date: Mon, 29 Sep 2008 20:01:57 +0000 MIME-Version: 1.0 Subject: Re: [Nea] Nea Digest, Vol 35, Issue 7 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rturner@amalfisystems.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org I thought there were two attributes we were considering... "Default pw enabled" and "forwarding enabled" Randy Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Nea Date: Mon, 29 Sep 2008 12:44:47 To: nea@ietf.org Cc: nea@ietf.org Subject: Re: [Nea] Nea Digest, Vol 35, Issue 7 So it appears the only one we are including in the document us 'default password enabled' and that I can't really tell by the forwarded email if we have consensus. I do think including that is wise if we have consensus. I am hum with all the WG decisions on these. Sent from my mobile, please excuse any typos. On Sep 29, 2008, at 12:00 PM, nea-request@ietf.org wrote: > Send Nea mailing list submissions to > nea@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/nea > or, via email, send a message with subject or body 'help' to > nea-request@ietf.org > > You can reach the person managing the list at > nea-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nea digest..." > > > Today's Topics: > > 1. Re: Consensus check on attributes suggested by Randy Turner > (Stephen Hanna) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 29 Sep 2008 09:33:01 -0400 > From: "Stephen Hanna" > Subject: Re: [Nea] Consensus check on attributes suggested by Randy > Turner > To: > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > The one week comment period on this proposal has expired. > The only comment that I received on this was from Randy Turner. > He agreed with the proposed resolution. > > This does not represent a huge amount of support but nobody > has voiced any concerns with the proposed resolution. Therefore, > I will ask the editors of PA-TNC to reflect this resolution > in the next revision of that document. There will be a full > WG Last Call on that spec coming soon so that will provide > another affirmation of support. > > Thanks, > > Steve > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On >> Behalf Of Stephen Hanna >> Sent: Friday, September 19, 2008 4:55 PM >> To: nea@ietf.org >> Subject: [Nea] Consensus check on attributes suggested by Randy >> Turner >> >> I have not seen any more dialog on the attributes that >> Randy Turner proposed. The PA-TNC editors need to prepare >> the next version of that draft and I think that we had pretty >> much reached consensus on how to handle these attributes >> so I propose a resolution below. I invite NEA participants >> to indicate whether you agree with this resolution. Please >> respond within one week (by Friday, September 26). If there >> is WG consensus in favor of this resolution, the editors >> will put it into the next PA-TNC draft. >> >> Thanks, >> >> Steve >> >> Forwarding Enabled >> ------------------ >> Most fixed-function endpoints can easily determine whether >> they are forwarding traffic between interfaces. Extensible >> endpoints may not be sure if they have multiple interfaces >> since application software can forward traffic. There is >> some security value in determining this value since it may >> indicate that a device which should not be forwarding traffic >> is doing so. Therefore, an IETF Standard PA-TNC Attribute Type >> will be defined, named "Forwarding Enabled". The Attribute Value >> for this attribute will be a single octet with one of three values: >> 0 ("Disabled") if the endpoint is not forwarding traffic >> between network interfaces, 1 ("Enabled") if the endpoint >> is forwarding traffic between network interfaces, and 2 >> ("Unknown") if it is not known whether the endpoint is >> forwarding traffic between network interfaces. >> >> Secure Time Enabled >> ------------------- >> This attribute is complex and we have not yet seen a proposal >> for it so we will not standardize it yet. It can come later, >> maybe using our process for defining new IETF Standard PA-TNC >> Attribute Types. >> >> Minimum Cipher Suite >> -------------------- >> We did not reach consensus in favor of standardizing this >> attribute. >> >> Configuration State >> ------------------- >> We did not reach consensus in favor of standardizing this >> attribute. >> >> PSTN_Fax_Enabled >> ---------------- >> This attribute is mainly for hard copy devices so it will >> be defined by the Printer Working Group . >> >> Factory Default Password Enabled >> -------------------------------- >> Many embedded devices include a default static password >> for administration. If this password is not changed before >> the device is placed in service, it's often easy to compromise >> the device. Therefore, it's desirable to identify devices >> that still have a factory default password enabled via NEA. >> A new PA-TNC attribute named "Factory Default Password Enabled" >> should be defined. The Attribute Value for this attribute >> will be a single octet with a value of 0 if the endpoint >> does not have a factory default password enabled and 1 if >> the endpoint does have such a password enabled. >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea >> > > > ------------------------------ > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > > > End of Nea Digest, Vol 35, Issue 7 > ********************************** _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Sep 29 15:00:57 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB103A6B83; Mon, 29 Sep 2008 15:00:57 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601923A6B83 for ; Mon, 29 Sep 2008 15:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMIlB7HpIMbs for ; Mon, 29 Sep 2008 15:00:55 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id AE9103A69DF for ; Mon, 29 Sep 2008 15:00:53 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Mon, 29 Sep 2008 15:00:31 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 15:00:43 -0700 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 15:00:42 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Sep 2008 18:00:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Sep 2008 18:00:34 -0400 Message-ID: In-Reply-To: <1351216721-1222718443-cardhu_decombobulator_blackberry.rim.net-695467506-@bxe014.bisx.prod.on.blackberry> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Nea Digest, Vol 35, Issue 7 Thread-Index: AckicWV7oUhq7hvhS4WIH9xJSdav/QADNoYg References: <48A0A41C-7549-48FA-A05A-5A19E51BAA77@gmail.com> <1351216721-1222718443-cardhu_decombobulator_blackberry.rim.net-695467506-@bxe014.bisx.prod.on.blackberry> From: "Stephen Hanna" To: , X-OriginalArrivalTime: 29 Sep 2008 22:00:41.0443 (UTC) FILETIME=[D0676330:01C9227E] Subject: Re: [Nea] Nea Digest, Vol 35, Issue 7 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org Randy is correct. The proposal was to add attributes for "Forwarding Enabled" and "Factory Default Password Enabled", defined as described below. Randy agreed with that. If rob.ietf.nea@gmail.com or someone else has any comments on this idea (maybe a hum?), that would be great. I apologize for the apparent lack of clarity in the proposal. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On > Behalf Of Randy Turner > Sent: Monday, September 29, 2008 4:02 PM > To: nea@ietf.org > Subject: Re: [Nea] Nea Digest, Vol 35, Issue 7 > > I thought there were two attributes we were considering... > "Default pw enabled" and "forwarding enabled" > > Randy > > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Nea > > Date: Mon, 29 Sep 2008 12:44:47 > To: nea@ietf.org > Cc: nea@ietf.org > Subject: Re: [Nea] Nea Digest, Vol 35, Issue 7 > > > So it appears the only one we are including in the document us > 'default password enabled' and that I can't really tell by the > forwarded email if we have consensus. I do think including that is > wise if we have consensus. > > I am hum with all the WG decisions on these. > > Sent from my mobile, please excuse any typos. > > On Sep 29, 2008, at 12:00 PM, nea-request@ietf.org wrote: > > > Send Nea mailing list submissions to > > nea@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/nea > > or, via email, send a message with subject or body 'help' to > > nea-request@ietf.org > > > > You can reach the person managing the list at > > nea-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Nea digest..." > > > > > > Today's Topics: > > > > 1. Re: Consensus check on attributes suggested by Randy Turner > > (Stephen Hanna) > > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 29 Sep 2008 09:33:01 -0400 > > From: "Stephen Hanna" > > Subject: Re: [Nea] Consensus check on attributes suggested by Randy > > Turner > > To: > > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > > The one week comment period on this proposal has expired. > > The only comment that I received on this was from Randy Turner. > > He agreed with the proposed resolution. > > > > This does not represent a huge amount of support but nobody > > has voiced any concerns with the proposed resolution. Therefore, > > I will ask the editors of PA-TNC to reflect this resolution > > in the next revision of that document. There will be a full > > WG Last Call on that spec coming soon so that will provide > > another affirmation of support. > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On > >> Behalf Of Stephen Hanna > >> Sent: Friday, September 19, 2008 4:55 PM > >> To: nea@ietf.org > >> Subject: [Nea] Consensus check on attributes suggested by Randy > >> Turner > >> > >> I have not seen any more dialog on the attributes that > >> Randy Turner proposed. The PA-TNC editors need to prepare > >> the next version of that draft and I think that we had pretty > >> much reached consensus on how to handle these attributes > >> so I propose a resolution below. I invite NEA participants > >> to indicate whether you agree with this resolution. Please > >> respond within one week (by Friday, September 26). If there > >> is WG consensus in favor of this resolution, the editors > >> will put it into the next PA-TNC draft. > >> > >> Thanks, > >> > >> Steve > >> > >> Forwarding Enabled > >> ------------------ > >> Most fixed-function endpoints can easily determine whether > >> they are forwarding traffic between interfaces. Extensible > >> endpoints may not be sure if they have multiple interfaces > >> since application software can forward traffic. There is > >> some security value in determining this value since it may > >> indicate that a device which should not be forwarding traffic > >> is doing so. Therefore, an IETF Standard PA-TNC Attribute Type > >> will be defined, named "Forwarding Enabled". The Attribute Value > >> for this attribute will be a single octet with one of three values: > >> 0 ("Disabled") if the endpoint is not forwarding traffic > >> between network interfaces, 1 ("Enabled") if the endpoint > >> is forwarding traffic between network interfaces, and 2 > >> ("Unknown") if it is not known whether the endpoint is > >> forwarding traffic between network interfaces. > >> > >> Secure Time Enabled > >> ------------------- > >> This attribute is complex and we have not yet seen a proposal > >> for it so we will not standardize it yet. It can come later, > >> maybe using our process for defining new IETF Standard PA-TNC > >> Attribute Types. > >> > >> Minimum Cipher Suite > >> -------------------- > >> We did not reach consensus in favor of standardizing this > >> attribute. > >> > >> Configuration State > >> ------------------- > >> We did not reach consensus in favor of standardizing this > >> attribute. > >> > >> PSTN_Fax_Enabled > >> ---------------- > >> This attribute is mainly for hard copy devices so it will > >> be defined by the Printer Working Group . > >> > >> Factory Default Password Enabled > >> -------------------------------- > >> Many embedded devices include a default static password > >> for administration. If this password is not changed before > >> the device is placed in service, it's often easy to compromise > >> the device. Therefore, it's desirable to identify devices > >> that still have a factory default password enabled via NEA. > >> A new PA-TNC attribute named "Factory Default Password Enabled" > >> should be defined. The Attribute Value for this attribute > >> will be a single octet with a value of 0 if the endpoint > >> does not have a factory default password enabled and 1 if > >> the endpoint does have such a password enabled. > >> _______________________________________________ > >> Nea mailing list > >> Nea@ietf.org > >> https://www.ietf.org/mailman/listinfo/nea > >> > > > > > > ------------------------------ > > > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www.ietf.org/mailman/listinfo/nea > > > > > > End of Nea Digest, Vol 35, Issue 7 > > ********************************** > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Sep 30 21:58:47 2008 Return-Path: X-Original-To: nea-archive@megatron.ietf.org Delivered-To: ietfarch-nea-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23AF03A6870; Tue, 30 Sep 2008 21:58:47 -0700 (PDT) X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9C83A6870 for ; Tue, 30 Sep 2008 21:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOThLTVCf6FK for ; Tue, 30 Sep 2008 21:58:45 -0700 (PDT) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by core3.amsl.com (Postfix) with ESMTP id 877C13A6849 for ; Tue, 30 Sep 2008 21:58:44 -0700 (PDT) Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m914x6jg018685 for ; Wed, 1 Oct 2008 00:59:06 -0400 Received: (qmail 23913 invoked by uid 78); 1 Oct 2008 04:59:06 -0000 Received: from unknown (HELO ?10.0.1.200?) (rturner@amalfisystems.com@71.119.122.114) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 1 Oct 2008 04:59:06 -0000 Message-Id: <097089F4-7DDB-4F80-928C-85D708BED3AE@amalfisystems.com> From: Randy Turner To: NEA Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 30 Sep 2008 21:59:04 -0700 X-Mailer: Apple Mail (2.929.2) Subject: [Nea] PA-subtypes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1214549204==" Sender: nea-bounces@ietf.org Errors-To: nea-bounces@ietf.org --===============1214549204== Content-Type: multipart/signed; boundary=Apple-Mail-6--283190861; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-6--283190861 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi All, I wasn't sure if the topic of PA subtypes was still open, but I was curious if anyone on the list had brought up the topic of device- drivers or "kernel extensions" as a way to indicate one way of sub- dividing the monolithic term "operating system". It seems reasonable to assume that someone might want to update a PKCS-11 driver or some other security-related kernel extension/module without updating the OS (from the perspective of remediation). Would not "kernel extension" be a good subtype designator for any type of uniquely identifiable/ upgradeable module in a system? At the moment, if there was a request for kernel extension information, the request would have to target the "operating system" subtype, which would be potentially a problem. Thanks! Randy --Apple-Mail-6--283190861 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGMzCCAuww ggJVoAMCAQICEFcOr//jUHkfUhTpkkg2ZOgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDcxNDAzNDIwMVoXDTA5MDcxNDAzNDIw MVowSzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEoMCYGCSqGSIb3DQEJARYZcnR1 cm5lckBhbWFsZmlzeXN0ZW1zLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMRP PdzSr6DBCtVR07ig3LZ7rlDRh4scX9NVPMooYTipX05CwFS/Zy7Cz96TCRfo0oNzIDaEuwyixIoj SQR7viToR8z8NXodL8cWOFThHturmbRzpdOsiVSsI9xDY0ut48gShRhOiDqh2oF/mcbN2hfygIfw 3KFiXO+38Iud/lZhMJa1PADry4aiigsss1iy50/yd8BcDFQTNCw2HGprtHDJznuwZlfxS9manJt0 /TQfi5zSG9+45m1MDaJp9d1dRdGvyAGwuOqdzQ/27pZqsEH/6OavdQ5FsL2i2e36VbMryBucmn/L BCwSfovQ1pQHorO+pphYJapjImTZVB0ZtsUCAwEAAaM2MDQwJAYDVR0RBB0wG4EZcnR1cm5lckBh bWFsZmlzeXN0ZW1zLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE0GLbM/YIk1 PgOw2J+pzA89C0xGPlmsouUdSzE1m0oEpe0tFHtb51xRU8uHVRLkRaiALHmegKNptYVJbMNy2j37 Zy5pmog/qciiEiBOVUX9X8fckTapueK7SI03s4QRvKGXD8W9WspF1L8vjCdL1JOCq6PTE1NFgf0s 0B7oVluSMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBXDq//41B5H1IU6ZJI NmToMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA4MTAwMTA0NTkwNVowIwYJKoZIhvcNAQkEMRYEFEYt//Vbj07Fo4unCyhswhMLh8LFMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVw6v/+NQeR9SFOmSSDZk6DCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVw6v/+NQeR9SFOmSSDZk6DANBgkqhkiG9w0BAQEF AASCAQA+4IuNmhQaplaMPZEi6ysvhQYRNs9yRGMI3fslL4VSc6SBwYabCcpexJTjYiEqj4rrTSsr fAEz2eHSlXOPS9WOffGMe9WwTE6CL8aDf9D3sFEoJPV3PRQ2O64Sw7PjlqkDKx1dOTubqMHoy59L 5zzqAAhMVpq82NSefdYadVol3OUFl0c/09amvpYwCJgobL2rtqZsfjbq8iblsukW+TITlUoLgbCn 7Pae4VnB4mKEzne0lNVIqbTmcOa32XqofWcZzmj3tqVkYhcLsnI5wkyVTqqhYy8axQ7cPQOgR7e4 jOpab1wvHx0x/ZGkOWYBak/lvJJb+qUHShDdNOHPK+U4AAAAAAAA --Apple-Mail-6--283190861-- --===============1214549204== 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://www.ietf.org/mailman/listinfo/nea --===============1214549204==--