From Pasi.Eronen@nokia.com Wed Apr 1 23:56:36 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9E13A6867; Wed, 1 Apr 2009 23:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 w3G9IhTwzoko; Wed, 1 Apr 2009 23:56:35 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AD7F93A683F; Wed, 1 Apr 2009 23:56:34 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n326vNXu021276; Thu, 2 Apr 2009 01:57:35 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 09:57:22 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 09:57:17 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 09:57:12 +0300 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 08:57:12 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Thu, 2 Apr 2009 08:57:11 +0200 From: To: , Date: Thu, 2 Apr 2009 08:57:15 +0200 Thread-Topic: Pasi's AD Notes for March 2009 Thread-Index: AcmzYEFJsaTcqRp8Q8qZVH+8Hexk4w== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F218F802@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Apr 2009 06:57:12.0339 (UTC) FILETIME=[3FAE4E30:01C9B360] X-Nokia-AV: Clean Subject: [saag] Pasi's AD Notes for March 2009 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 06:56:36 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - I and Tim need to edit the SAAG minutes and post them [since 2009-03-26] - We have received a liaison statement from ITU-T SG 17; I and Tim=20 need to organize a response. - (not wearing AD hat): Errata #1628 (for RFC 4742): waiting for NETCONF WG chairs/Dan to confirm this [since 2009-02-26] WORKING GROUPS DKIM - draft-ietf-dkim-rfc4871-errata: lots of emails that I haven't read yet. - draft-ietf-dkim-ssp: waiting for the errata dust to settle=20 (probably small changes to Section 2.7, either editorial or technical,=20 are needed no matter how this turns out) - draft-ietf-dkim-overview: waiting for authors to submit a revised ID addressing my AD review comments (except perhaps the first=20 one -- that may require more discussion) and Barry's editorial=20 nits (off-list 2008-10-28...2008-11-12) [since 2009-02-27] - Waiting for WG to send list of RFC errata IDs (the non-controversial ones, not related to d=3D/i=3D) the WG agrees on. EMU - (not WG items) New RFCs: RFC 5421 and 5422 IPSECME - (not wearing hats) draft-ietf-ipsecme-ikev2-ipv6-config: I promised to update the draft (clean it, address TBDs) so it would be ready=20 for WGLC (as Experimental) if this path is chosen by WG. ISMS - draft-ietf-isms-secshell, draft-ietf-isms-tmsm, and draft-ietf-isms-transport-security-model: going to IETF last call - draft-ietf-isms-radius-usage: waiting for me to do my AD=20 review [since 2009-03-27] - Discussions about rechartering; waiting for concrete proposal =20 from David/Jeff/Wes/etc. KEYPROV - Lots of emails I need to read since IETF74... PKIX - Note: I'm shepherding two PKIX drafts where Tim is a co-author - draft-ietf-pkix-ecc-subpubkeyinfo: now published as RFC 5480 - draft-ietf-pkix-rfc4055-update: was approved by IESG, now in=20 RFC Editor queue SASL - Some progress on SCRAM/GS2 SYSLOG - Four new RFCs: RFC 5424, 5425, 5426, 5427 - draft-ietf-syslog-sign: waiting for me to read version -25=20 [since 2009-03-31] - Discussions about rechartering (either in SEC or OPS area) or closing down. TLS - draft-ietf-tls-ecdhe-psk: now published as RFC 5489 - draft-ietf-tls-psk-new-mac-aes-gcm: now published as RFC 5487 - (not WG item) draft-rescorla-tls-suiteb: now published as RFC 5430 - (not WG item yet) Apparently some folks are interested in getting draft-rescorla-tls-extended-random published (and an implementation exists). I was hoping to see a presentation in San Francisco, but that didn't happen -- perhaps something happens on the mailing list. - (not WG item yet) I need to talk with the chairs and Michael about what to do with Mobi-D OTHER DOCUMENTS - draft-lebovitz-kmart-roadmap: I need to read this and=20 comment/contribute. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. DISCUSSES (active -- something happened within last month) - draft-ietf-bfd-base: text agreed, waiting for authors to submit=20 a revised ID [since 2009-03-19] - draft-ietf-btns-connection-latching: waiting for me to read the new version -09 [since 2009-03-26] - draft-ietf-calsify-rfc2445bis: changes agreed, waiting for=20 the authors to submit a revised ID [since 2009-03-31] - draft-ietf-l2tpext-tdm: waiting for authors to submit a revised ID and Ralph to re-do the IETF last call [since 2009-02-07] - draft-ietf-monami6-multiplecoa: some text agreed; discussed the IPsec problem in IETF74, and came to rough agreement on how to solve it; waiting for authors to propose concrete text [since 2009-03-24] - draft-ietf-ospf-lls: version -07 did not address my comments; waiting for a revised ID or RFC Editor Notes [since 2009-03-19] - draft-ietf-softwire-encaps-ipsec: I think we roughly agreed on how to solve the initiator authentication problem; waiting for authors to propose concrete text [since 2009-03-27] - draft-igoe-secsh-aes-gcm: waiting for Tim to send email to=20 secsh list/other folks [since 2009-03-22] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-cain-post-inch-phishingextns: authors have promised a new version some time in February [since 2009-01-29] - draft-ietf-radext-management-authorization: waiting for authors to reply to my comments [since 2009-01-28] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-07] (but talked briefly with Radia at IETF74) - draft-ietf-sip-xcapevent: waiting for revised ID or RFC Editor Note to fix the ABNF/XML bugs [since 2008-10-24] - draft-ietf-sipping-policy-package: waiting for more information from Mary or Jon [since 2008-10-28] --end--= From Nicolas.Williams@sun.com Thu Apr 2 08:52:19 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8025F3A6DE7; Thu, 2 Apr 2009 08:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.767 X-Spam-Level: X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 ioKOpZ6bxFti; Thu, 2 Apr 2009 08:52:18 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id B9A493A6DAE; Thu, 2 Apr 2009 08:52:18 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n32FrKAh006706; Thu, 2 Apr 2009 15:53:20 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n32FrJVd011156; Thu, 2 Apr 2009 09:53:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n32Fi2Ge001972; Thu, 2 Apr 2009 10:44:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n32Fi2Tt001971; Thu, 2 Apr 2009 10:44:02 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 2 Apr 2009 10:44:02 -0500 From: Nicolas Williams To: saag@ietf.org Message-ID: <20090402154402.GM1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, nfsv4@ietf.org, nfs-discuss@opensolaris.org Subject: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 15:52:19 -0000 Over at the NFSv4 WG we've been having a discussion of a labeled NFSv4 proposal. [Note: NFSv4 WG and others cc'ed, Reply-To: set to SAAG.] An interop issue has arisen that we believe applies equally to CALIPSO (draft-stjohns-sipso-11.txt)and requires input from the IETF security area. The issue is: how do do nodes in a labeled network/application know if they agree on a common labeled security policy for a given DOI? Agreeing on a DOI is accomplished easily enough -- that's not an issue. Agreeing on what a given numeric sensitivity level or compartment bit means in a given DOI is quite another. Without a solution to this we're left with out-of-band agreement, which leaves interop in a lurch. I think we need a generic MLS and DTE labeled security policy document format that allows a DOI to define the names and numeric assignments of sensitivity levels, compartments, etcetera. We also need a way for nodes to agree that they have the same policy for a given DOI, or that they agree on a common subset of a DOI's policy. This last problem can be solved by use of a labeled security policy URI scheme that includes a version number (+ a requirement that changes be in the form of additions and obsolescence of old assignments, but not removals). To recap: I think we need a) a common MLS and DTE labeled security policy document format, b) a labeled security policy URI scheme to refer to such documents by. Given (a) and (b) NFSv4.x clients and servers would only have to exchange {DOI #, policy URI} tuples to determine whether they agree on a common policy. Note that CALIPSO describes how to encode and compare MLS labels on the wire, but it does not describe how nodes agree on the meaning of particular sensitivity levels or compartments. Therefore CALIPSO is going to have much the same problem as NFSv4. Nico -- From tlr@w3.org Fri Apr 3 02:13:14 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F693A67B7 for ; Fri, 3 Apr 2009 02:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.002 X-Spam-Level: X-Spam-Status: No, score=-10.002 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 DSC3L8Hx3vZL for ; Fri, 3 Apr 2009 02:13:13 -0700 (PDT) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id BD8A93A68C7 for ; Fri, 3 Apr 2009 02:13:02 -0700 (PDT) Received: from iCoaster.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 5E18C4EF69; Fri, 3 Apr 2009 05:14:04 -0400 (EDT) Received: from localhost ([127.0.0.1]) by iCoaster.does-not-exist.org with esmtp (Exim 4.66) (envelope-from ) id KHHGF1-001VIR-PY; Thu, 02 Apr 2009 18:57:01 +0200 Message-Id: From: Thomas Roessler To: saag@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-49-538700211 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 18:57:01 +0200 References: <120077F4-0B65-4032-B5A2-FA8FA1330695@nokia.com> X-Mailer: Apple Mail (2.930.3) Cc: Arthur Barstow , Frederick Hirsch Subject: [saag] Fwd: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 09:13:14 -0000 --Apple-Mail-49-538700211 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit FYI. Note that the document is referencing an upcoming version of XML Signature, which is currently in Working Draft status. There is an expectation that this profile (not the base spec) might undergo a W3C last call relatively soon, so this would be a good time to review the specification. -- Thomas Roessler, W3C Begin forwarded message: > From: Arthur Barstow > Date: 2 April 2009 18:21:19 GMT+02:00 > To: public-webapps > Subject: [widgets] New WD of Widgets 1.0: Digital Signatures spec > published on March 31 > Archived-At: > > > On March 31 a new WD of the Widgets 1.0 Digital Signature spec was > published and announced on the W3C's home page: > > [[ > 2009-03-31: The Web Applications Working Group has published a > Working Draft of Widgets 1.0: Digital Signatures. This document > defines a profile of the XML Signature Syntax and Processing 1.1 > specification to allow a widget package to be digitally signed. > Widget authors and distributors can digitally sign widgets as a > trust and quality assurance mechanism. Prior to instantiation, a > user agent can use the digital signature to verify the integrity of > the widget package and perform source authentication. This document > specifies conformance requirements on both widget packages and user > agents. > ]] > > Please review this new WD as soon as possible, preferably within the > next two weeks: > > > > -Regards, Art Barstow > --Apple-Mail-49-538700211 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable FYI.

Note = that the document is referencing an upcoming version of XML Signature, = which is currently in Working Draft = status.

There is an expectation that this = profile (not the base spec) might undergo a W3C last call relatively = soon, so this would be a good time to review the = specification.

--
Thomas Roessler, W3C  <tlr@w3.org>

Begin = forwarded message:

From: = Arthur Barstow <art.barstow@nokia.com>=
Date: 2 April 2009 18:21:19 = GMT+02:00
To: public-webapps <public-webapps@w3.org>=
Subject: [widgets] New WD of Widgets 1.0: = Digital Signatures spec published on March 31

=
On March 31 a new WD of the Widgets 1.0 Digital Signature = spec was published and announced on the W3C's home = page:

[[
2009-03-31: The Web Applications Working Group has = published a Working Draft of Widgets 1.0: Digital Signatures. This = document defines a profile of the XML Signature Syntax and Processing = 1.1 specification to allow a widget package to be digitally signed. = Widget authors and distributors can digitally sign widgets as a trust = and quality assurance mechanism. Prior to instantiation, a user agent = can use the digital signature to verify the integrity of the widget = package and perform source authentication. This document specifies = conformance requirements on both widget packages and user = agents.
]]

Please review this new WD as soon as possible, = preferably within the next two weeks:

<http://www.= w3.org/TR/2009/WD-widgets-digsig-20090331/>

-Regards, Art = Barstow


= --Apple-Mail-49-538700211-- From SChokhani@cygnacom.com Fri Apr 3 08:21:37 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7451528C282 for ; Fri, 3 Apr 2009 08:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 pHw4d6RkPzjo for ; Fri, 3 Apr 2009 08:21:36 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 79B763A6862 for ; Fri, 3 Apr 2009 08:21:36 -0700 (PDT) Received: (qmail 8302 invoked from network); 3 Apr 2009 15:21:32 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 3 Apr 2009 15:21:32 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 11:22:38 -0400 Message-ID: In-Reply-To: <20090402154402.GM1500@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: AcmzqyjnktCJdE01TAayDuJGh7ueugAvoXsw References: <20090402154402.GM1500@Sun.COM> From: "Santosh Chokhani" To: Cc: labeled-nfs@linux-nfs.org, nfs-discuss@opensolaris.org, nfsv4@ietf.org, selinux@tycho.nsa.gov Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:21:37 -0000 As part of MISSI and DMS, in mid to late 90's we did work on something called Security Policy Information File (SPIF). At high level SPIF entailed the following: 1. It was ASN.1 based. 2. It permitted you to convert the machine representation to human readable representation. 3. It permitted you to convert the human readable input to machine representation. 4. It mapped labels (hierarchical sensitivity levels and non-hierarchical categories) from one labeling policy to another (i.e., establish equivalency mapping) 5. It allowed you to constrain labels since for some policies, existence of a category may mean some categories, levels, may be included and/or excluded. Different labeling policies were indicated by different policy OID. Some of the concept from that work may be applicable here.=20 > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On=20 > Behalf Of Nicolas Williams > Sent: Thursday, April 02, 2009 11:44 AM > To: saag@ietf.org > Cc: labeled-nfs@linux-nfs.org; selinux@tycho.nsa.gov;=20 > nfsv4@ietf.org; nfs-discuss@opensolaris.org > Subject: [saag] Common labeled security (comment on CALIPSO,=20 > labeled NFSv4) >=20 > Over at the NFSv4 WG we've been having a discussion of a=20 > labeled NFSv4 proposal. [Note: NFSv4 WG and others cc'ed,=20 > Reply-To: set to SAAG.] >=20 > An interop issue has arisen that we believe applies equally=20 > to CALIPSO (draft-stjohns-sipso-11.txt)and requires input=20 > from the IETF security area. >=20 > The issue is: how do do nodes in a labeled=20 > network/application know if they agree on a common labeled=20 > security policy for a given DOI? >=20 > Agreeing on a DOI is accomplished easily enough -- that's not=20 > an issue. > Agreeing on what a given numeric sensitivity level or=20 > compartment bit means in a given DOI is quite another. =20 > Without a solution to this we're left with out-of-band=20 > agreement, which leaves interop in a lurch. >=20 > I think we need a generic MLS and DTE labeled security policy=20 > document format that allows a DOI to define the names and=20 > numeric assignments of sensitivity levels, compartments, etcetera. >=20 > We also need a way for nodes to agree that they have the same=20 > policy for a given DOI, or that they agree on a common subset=20 > of a DOI's policy. >=20 > This last problem can be solved by use of a labeled security=20 > policy URI scheme that includes a version number (+ a=20 > requirement that changes be in the form of additions and=20 > obsolescence of old assignments, but not removals). >=20 > To recap: I think we need a) a common MLS and DTE labeled=20 > security policy document format, b) a labeled security policy=20 > URI scheme to refer to such documents by. >=20 > Given (a) and (b) NFSv4.x clients and servers would only have=20 > to exchange {DOI #, policy URI} tuples to determine whether=20 > they agree on a common policy. >=20 > Note that CALIPSO describes how to encode and compare MLS=20 > labels on the wire, but it does not describe how nodes agree=20 > on the meaning of particular sensitivity levels or=20 > compartments. Therefore CALIPSO is going to have much the=20 > same problem as NFSv4. >=20 > Nico > -- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 From Nicolas.Williams@sun.com Fri Apr 3 09:21:13 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4533A67FB; Fri, 3 Apr 2009 09:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 4R3qt7zHL5tJ; Fri, 3 Apr 2009 09:21:12 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 9FACF3A67BD; Fri, 3 Apr 2009 09:21:12 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n33GMDYF019976; Fri, 3 Apr 2009 16:22:13 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n33GMCMS062310; Fri, 3 Apr 2009 10:22:12 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33FgtDi002886; Fri, 3 Apr 2009 10:42:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33Fgs5b002885; Fri, 3 Apr 2009 10:42:54 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 3 Apr 2009 10:42:54 -0500 From: Nicolas Williams To: Santosh Chokhani Message-ID: <20090403154253.GZ1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, saag@ietf.org, nfs-discuss@opensolaris.org, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:21:13 -0000 On Fri, Apr 03, 2009 at 11:22:38AM -0400, Santosh Chokhani wrote: > As part of MISSI and DMS, in mid to late 90's we did work on something > called Security Policy Information File (SPIF). Oh, very nice! Thanks for the pointer. That would be ISO15816. I've found the spec, though it's non-free (hadn't they learned the lesson with ASN.1?? will they ever learn it??). > At high level SPIF entailed the following: > > 1. It was ASN.1 based. Not surprisingly :) Converting that to XML is probably the correct first step in order to ensure adoption, sadly. (Actually, apparently that has already been done once, though outside the ISO/ITU-T.) > 2. It permitted you to convert the machine representation to human > readable representation. > 3. It permitted you to convert the human readable input to machine > representation. > 4. It mapped labels (hierarchical sensitivity levels and > non-hierarchical categories) from one labeling policy to another (i.e., > establish equivalency mapping) > 5. It allowed you to constrain labels since for some policies, > existence of a category may mean some categories, levels, may be > included and/or excluded. > > Different labeling policies were indicated by different policy OID. > > Some of the concept from that work may be applicable here. I think so! Except for the part about this spec being non-free. I think that means: start over in the IETF. Nico -- From scampbell@assureddecisions.com Fri Apr 3 09:38:52 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAD328C123; Fri, 3 Apr 2009 09:38:52 -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 Sh0tueG6vo3M; Fri, 3 Apr 2009 09:38:51 -0700 (PDT) Received: from smtp1.netvigour.com (smtp1.netvigour.com [144.202.247.31]) by core3.amsl.com (Postfix) with ESMTP id 82C3A3A6358; Fri, 3 Apr 2009 09:38:51 -0700 (PDT) Received: from E2K7CCR1.netvigour.com ([10.201.10.17]) by mail10.netvigour.com ([10.201.10.15]) with mapi; Fri, 3 Apr 2009 12:36:16 -0400 From: Shawn Campbell To: Santosh Chokhani , "saag@ietf.org" Date: Fri, 3 Apr 2009 12:34:20 -0400 Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: AcmzqyjnktCJdE01TAayDuJGh7ueugAvoXswAAQW6lE= Message-ID: <1429AAAB538ACD47902CFCA6954C566B16F22910@E2K7CCR1.netvigour.com> References: <20090402154402.GM1500@Sun.COM>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "labeled-nfs@linux-nfs.org" , "selinux@tycho.nsa.gov" , "nfsv4@ietf.org" , "nfs-discuss@opensolaris.org" Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:38:52 -0000 Similar activity with SILS 802.10 work involved SDE security labels. Thoug= h that has been disbanded, some of that may be a help in this area. ________________________________________ From: saag-bounces@ietf.org [saag-bounces@ietf.org] On Behalf Of Santosh Ch= okhani [SChokhani@cygnacom.com] Sent: Friday, April 03, 2009 11:22 AM To: saag@ietf.org Cc: labeled-nfs@linux-nfs.org; nfs-discuss@opensolaris.org; nfsv4@ietf.org;= selinux@tycho.nsa.gov Subject: Re: [saag] Common labeled security (comment on CALIPSO, lab= eled NFSv4) As part of MISSI and DMS, in mid to late 90's we did work on something called Security Policy Information File (SPIF). At high level SPIF entailed the following: 1. It was ASN.1 based. 2. It permitted you to convert the machine representation to human readable representation. 3. It permitted you to convert the human readable input to machine representation. 4. It mapped labels (hierarchical sensitivity levels and non-hierarchical categories) from one labeling policy to another (i.e., establish equivalency mapping) 5. It allowed you to constrain labels since for some policies, existence of a category may mean some categories, levels, may be included and/or excluded. Different labeling policies were indicated by different policy OID. Some of the concept from that work may be applicable here. > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On > Behalf Of Nicolas Williams > Sent: Thursday, April 02, 2009 11:44 AM > To: saag@ietf.org > Cc: labeled-nfs@linux-nfs.org; selinux@tycho.nsa.gov; > nfsv4@ietf.org; nfs-discuss@opensolaris.org > Subject: [saag] Common labeled security (comment on CALIPSO, > labeled NFSv4) > > Over at the NFSv4 WG we've been having a discussion of a > labeled NFSv4 proposal. [Note: NFSv4 WG and others cc'ed, > Reply-To: set to SAAG.] > > An interop issue has arisen that we believe applies equally > to CALIPSO (draft-stjohns-sipso-11.txt)and requires input > from the IETF security area. > > The issue is: how do do nodes in a labeled > network/application know if they agree on a common labeled > security policy for a given DOI? > > Agreeing on a DOI is accomplished easily enough -- that's not > an issue. > Agreeing on what a given numeric sensitivity level or > compartment bit means in a given DOI is quite another. > Without a solution to this we're left with out-of-band > agreement, which leaves interop in a lurch. > > I think we need a generic MLS and DTE labeled security policy > document format that allows a DOI to define the names and > numeric assignments of sensitivity levels, compartments, etcetera. > > We also need a way for nodes to agree that they have the same > policy for a given DOI, or that they agree on a common subset > of a DOI's policy. > > This last problem can be solved by use of a labeled security > policy URI scheme that includes a version number (+ a > requirement that changes be in the form of additions and > obsolescence of old assignments, but not removals). > > To recap: I think we need a) a common MLS and DTE labeled > security policy document format, b) a labeled security policy > URI scheme to refer to such documents by. > > Given (a) and (b) NFSv4.x clients and servers would only have > to exchange {DOI #, policy URI} tuples to determine whether > they agree on a common policy. > > Note that CALIPSO describes how to encode and compare MLS > labels on the wire, but it does not describe how nodes agree > on the meaning of particular sensitivity levels or > compartments. Therefore CALIPSO is going to have much the > same problem as NFSv4. > > Nico > -- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From housley@vigilsec.com Fri Apr 3 09:44:07 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0003A6C34; Fri, 3 Apr 2009 09:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 POn8El7TmNbW; Fri, 3 Apr 2009 09:44:06 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 727463A6816; Fri, 3 Apr 2009 09:44:06 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 3D4EA9A4741; Fri, 3 Apr 2009 12:45:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id svcIV2yhX9S4; Fri, 3 Apr 2009 12:45:07 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-71-191-197-15.washdc.fios.verizon.net [71.191.197.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DEA9A9A4739; Fri, 3 Apr 2009 12:45:22 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Apr 2009 12:44:30 -0400 To: "Santosh Chokhani" , From: Russ Housley In-Reply-To: References: <20090402154402.GM1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090403164522.DEA9A9A4739@odin.smetech.net> Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, nfsv4@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:44:07 -0000 I really do not have time to write about all of my concerns. However, once you get beyond the basic classifications, the SPIF model breaks. They are markings that are only to be known to people that have the clearance for those markings, this leads to a SPIF distribution nightmare, as a subset of the real SPIF must be given out based on access (or not) to various compartments and such. It just does not scale. Russ At 11:22 AM 4/3/2009, Santosh Chokhani wrote: >As part of MISSI and DMS, in mid to late 90's we did work on something >called Security Policy Information File (SPIF). > >At high level SPIF entailed the following: > >1. It was ASN.1 based. >2. It permitted you to convert the machine representation to human >readable representation. >3. It permitted you to convert the human readable input to machine >representation. >4. It mapped labels (hierarchical sensitivity levels and >non-hierarchical categories) from one labeling policy to another (i.e., >establish equivalency mapping) >5. It allowed you to constrain labels since for some policies, >existence of a category may mean some categories, levels, may be >included and/or excluded. > >Different labeling policies were indicated by different policy OID. > >Some of the concept from that work may be applicable here. > > > -----Original Message----- > > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On > > Behalf Of Nicolas Williams > > Sent: Thursday, April 02, 2009 11:44 AM > > To: saag@ietf.org > > Cc: labeled-nfs@linux-nfs.org; selinux@tycho.nsa.gov; > > nfsv4@ietf.org; nfs-discuss@opensolaris.org > > Subject: [saag] Common labeled security (comment on CALIPSO, > > labeled NFSv4) > > > > Over at the NFSv4 WG we've been having a discussion of a > > labeled NFSv4 proposal. [Note: NFSv4 WG and others cc'ed, > > Reply-To: set to SAAG.] > > > > An interop issue has arisen that we believe applies equally > > to CALIPSO (draft-stjohns-sipso-11.txt)and requires input > > from the IETF security area. > > > > The issue is: how do do nodes in a labeled > > network/application know if they agree on a common labeled > > security policy for a given DOI? > > > > Agreeing on a DOI is accomplished easily enough -- that's not > > an issue. > > Agreeing on what a given numeric sensitivity level or > > compartment bit means in a given DOI is quite another. > > Without a solution to this we're left with out-of-band > > agreement, which leaves interop in a lurch. > > > > I think we need a generic MLS and DTE labeled security policy > > document format that allows a DOI to define the names and > > numeric assignments of sensitivity levels, compartments, etcetera. > > > > We also need a way for nodes to agree that they have the same > > policy for a given DOI, or that they agree on a common subset > > of a DOI's policy. > > > > This last problem can be solved by use of a labeled security > > policy URI scheme that includes a version number (+ a > > requirement that changes be in the form of additions and > > obsolescence of old assignments, but not removals). > > > > To recap: I think we need a) a common MLS and DTE labeled > > security policy document format, b) a labeled security policy > > URI scheme to refer to such documents by. > > > > Given (a) and (b) NFSv4.x clients and servers would only have > > to exchange {DOI #, policy URI} tuples to determine whether > > they agree on a common policy. > > > > Note that CALIPSO describes how to encode and compare MLS > > labels on the wire, but it does not describe how nodes agree > > on the meaning of particular sensitivity levels or > > compartments. Therefore CALIPSO is going to have much the > > same problem as NFSv4. > > > > Nico > > -- > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From Nicolas.Williams@sun.com Fri Apr 3 10:30:08 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936F13A6954; Fri, 3 Apr 2009 10:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.805 X-Spam-Level: X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 wF91ZE8fq87j; Fri, 3 Apr 2009 10:30:07 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 7CC9B3A6859; Fri, 3 Apr 2009 10:29:59 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n33HV2Rk012473; Fri, 3 Apr 2009 17:31:02 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n33HV1T6024004; Fri, 3 Apr 2009 11:31:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33Gpili002956; Fri, 3 Apr 2009 11:51:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33GpiRE002955; Fri, 3 Apr 2009 11:51:44 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 3 Apr 2009 11:51:44 -0500 From: Nicolas Williams To: Russ Housley Message-ID: <20090403165143.GC1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090403164522.DEA9A9A4739@odin.smetech.net> User-Agent: Mutt/1.5.7i Cc: selinux@tycho.nsa.gov, labeled-nfs@linux-nfs.org, nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Santosh Chokhani Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:30:08 -0000 On Fri, Apr 03, 2009 at 12:44:30PM -0400, Russ Housley wrote: > I really do not have time to write about all of my > concerns. However, once you get beyond the basic classifications, > the SPIF model breaks. They are markings that are only to be known > to people that have the clearance for those markings, this leads to a > SPIF distribution nightmare, as a subset of the real SPIF must be > given out based on access (or not) to various compartments and > such. It just does not scale. I'm aware of the fact that labels can themselves be labeled. But I don't think that implies that we can't make a SPIF-like solution scale. Peers that have access to different subsets of the policy should still be able to interop if care is taken to specify what happens when a node sees a label that falls outside its policy subset, and provided, of course, that the peers can agree that they have subsets of the *same* master policy. Peers can check whether they do have subsets of the *same* master policy by exchanging [for each DOI to both] a master policy URI that includes a version number. Nico -- From SChokhani@cygnacom.com Fri Apr 3 10:33:23 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3021E3A6CFD for ; Fri, 3 Apr 2009 10:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 HGP9MgExEomf for ; Fri, 3 Apr 2009 10:33:22 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 13E8A3A67EC for ; Fri, 3 Apr 2009 10:33:21 -0700 (PDT) Received: (qmail 9310 invoked from network); 3 Apr 2009 17:33:18 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 3 Apr 2009 17:33:18 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 13:34:23 -0400 Message-ID: In-Reply-To: <20090403154253.GZ1500@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm0d01GRvibCgHAQZGBDXiN3KXFSwACwt3g References: <20090402154402.GM1500@Sun.COM> <20090403154253.GZ1500@Sun.COM> From: "Santosh Chokhani" To: "Nicolas Williams" Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, saag@ietf.org, nfs-discuss@opensolaris.org, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:33:23 -0000 The work I am mentioning was done for NSA and can be released if NSA is ok with it. I suspect NSA will be ok with it.=20 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Friday, April 03, 2009 11:43 AM > To: Santosh Chokhani > Cc: saag@ietf.org; labeled-nfs@linux-nfs.org;=20 > nfs-discuss@opensolaris.org; nfsv4@ietf.org; selinux@tycho.nsa.gov > Subject: Re: [saag] Common labeled security (comment on=20 > CALIPSO, labeled NFSv4) >=20 > On Fri, Apr 03, 2009 at 11:22:38AM -0400, Santosh Chokhani wrote: > > As part of MISSI and DMS, in mid to late 90's we did work=20 > on something=20 > > called Security Policy Information File (SPIF). >=20 > Oh, very nice! Thanks for the pointer. That would be=20 > ISO15816. I've found the spec, though it's non-free (hadn't=20 > they learned the lesson with ASN.1?? will they ever learn it??). >=20 > > At high level SPIF entailed the following: > >=20 > > 1. It was ASN.1 based. >=20 > Not surprisingly :) Converting that to XML is probably the=20 > correct first step in order to ensure adoption, sadly. =20 > (Actually, apparently that has already been done once, though=20 > outside the ISO/ITU-T.) >=20 > > 2. It permitted you to convert the machine representation to human=20 > > readable representation. > > 3. It permitted you to convert the human readable input to machine=20 > > representation. > > 4. It mapped labels (hierarchical sensitivity levels and=20 > > non-hierarchical categories) from one labeling policy to another=20 > > (i.e., establish equivalency mapping) 5. It allowed you to=20 > constrain=20 > > labels since for some policies, existence of a category may=20 > mean some=20 > > categories, levels, may be included and/or excluded. > >=20 > > Different labeling policies were indicated by different policy OID. > >=20 > > Some of the concept from that work may be applicable here.=20 >=20 > I think so! Except for the part about this spec being=20 > non-free. I think that means: start over in the IETF. >=20 > Nico > --=20 >=20 From SChokhani@cygnacom.com Fri Apr 3 10:35:16 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA603A68F6 for ; Fri, 3 Apr 2009 10:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 Rq5WA3Y7ALGz for ; Fri, 3 Apr 2009 10:35:15 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 65C5C3A67EC for ; Fri, 3 Apr 2009 10:35:15 -0700 (PDT) Received: (qmail 9337 invoked from network); 3 Apr 2009 17:35:11 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 3 Apr 2009 17:35:11 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 13:36:17 -0400 Message-ID: In-Reply-To: <20090403164522.DEA9A9A4739@odin.smetech.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm0e419oIPXSskwQs+RejW2LvMIOQABwq5g References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> From: "Santosh Chokhani" To: "Russ Housley" , Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, nfsv4@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:35:16 -0000 Russ, My thinking was that the features of SPIF that are not needed could be discarded. I was hoping that we could help the group save the baby and throw out the bath water.=20 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: Friday, April 03, 2009 12:45 PM > To: Santosh Chokhani; saag@ietf.org > Cc: labeled-nfs@linux-nfs.org; nfs-discuss@opensolaris.org;=20 > nfsv4@ietf.org; selinux@tycho.nsa.gov > Subject: Re: [saag] Common labeled security (comment on=20 > CALIPSO, labeled NFSv4) >=20 > I really do not have time to write about all of my concerns. =20 > However, once you get beyond the basic classifications, the=20 > SPIF model breaks. They are markings that are only to be=20 > known to people that have the clearance for those markings,=20 > this leads to a SPIF distribution nightmare, as a subset of=20 > the real SPIF must be given out based on access (or not) to=20 > various compartments and such. It just does not scale. >=20 > Russ >=20 > At 11:22 AM 4/3/2009, Santosh Chokhani wrote: > >As part of MISSI and DMS, in mid to late 90's we did work on=20 > something=20 > >called Security Policy Information File (SPIF). > > > >At high level SPIF entailed the following: > > > >1. It was ASN.1 based. > >2. It permitted you to convert the machine representation to human=20 > >readable representation. > >3. It permitted you to convert the human readable input to machine=20 > >representation. > >4. It mapped labels (hierarchical sensitivity levels and=20 > >non-hierarchical categories) from one labeling policy to=20 > another (i.e.,=20 > >establish equivalency mapping) 5. It allowed you to=20 > constrain labels=20 > >since for some policies, existence of a category may mean some=20 > >categories, levels, may be included and/or excluded. > > > >Different labeling policies were indicated by different policy OID. > > > >Some of the concept from that work may be applicable here. > > > > > -----Original Message----- > > > From: saag-bounces@ietf.org=20 > [mailto:saag-bounces@ietf.org] On Behalf=20 > > > Of Nicolas Williams > > > Sent: Thursday, April 02, 2009 11:44 AM > > > To: saag@ietf.org > > > Cc: labeled-nfs@linux-nfs.org; selinux@tycho.nsa.gov;=20 > > > nfsv4@ietf.org; nfs-discuss@opensolaris.org > > > Subject: [saag] Common labeled security (comment on=20 > CALIPSO, labeled=20 > > > NFSv4) > > > > > > Over at the NFSv4 WG we've been having a discussion of a labeled=20 > > > NFSv4 proposal. [Note: NFSv4 WG and others cc'ed, > > > Reply-To: set to SAAG.] > > > > > > An interop issue has arisen that we believe applies equally to=20 > > > CALIPSO (draft-stjohns-sipso-11.txt)and requires input=20 > from the IETF=20 > > > security area. > > > > > > The issue is: how do do nodes in a labeled=20 > network/application know=20 > > > if they agree on a common labeled security policy for a given DOI? > > > > > > Agreeing on a DOI is accomplished easily enough -- that's not an=20 > > > issue. > > > Agreeing on what a given numeric sensitivity level or compartment=20 > > > bit means in a given DOI is quite another. > > > Without a solution to this we're left with out-of-band agreement,=20 > > > which leaves interop in a lurch. > > > > > > I think we need a generic MLS and DTE labeled security policy=20 > > > document format that allows a DOI to define the names and numeric=20 > > > assignments of sensitivity levels, compartments, etcetera. > > > > > > We also need a way for nodes to agree that they have the=20 > same policy=20 > > > for a given DOI, or that they agree on a common subset of a DOI's=20 > > > policy. > > > > > > This last problem can be solved by use of a labeled=20 > security policy=20 > > > URI scheme that includes a version number (+ a requirement that=20 > > > changes be in the form of additions and obsolescence of old=20 > > > assignments, but not removals). > > > > > > To recap: I think we need a) a common MLS and DTE labeled=20 > security=20 > > > policy document format, b) a labeled security policy URI=20 > scheme to=20 > > > refer to such documents by. > > > > > > Given (a) and (b) NFSv4.x clients and servers would only have to=20 > > > exchange {DOI #, policy URI} tuples to determine whether=20 > they agree=20 > > > on a common policy. > > > > > > Note that CALIPSO describes how to encode and compare MLS=20 > labels on=20 > > > the wire, but it does not describe how nodes agree on the=20 > meaning of=20 > > > particular sensitivity levels or compartments. Therefore=20 > CALIPSO is=20 > > > going to have much the same problem as NFSv4. > > > > > > Nico > > > -- > > > _______________________________________________ > > > saag mailing list > > > saag@ietf.org > > > https://www.ietf.org/mailman/listinfo/saag > > > > >_______________________________________________ > >saag mailing list > >saag@ietf.org > >https://www.ietf.org/mailman/listinfo/saag >=20 >=20 From SChokhani@cygnacom.com Fri Apr 3 10:43:14 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80CF28C138 for ; Fri, 3 Apr 2009 10:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 gZ1KKtPTaSka for ; Fri, 3 Apr 2009 10:43:14 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 796F43A6891 for ; Fri, 3 Apr 2009 10:42:47 -0700 (PDT) Received: (qmail 9383 invoked from network); 3 Apr 2009 17:42:43 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 3 Apr 2009 17:42:43 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 13:43:49 -0400 Message-ID: In-Reply-To: <20090403165143.GC1500@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm0gOo0x3crKQOVTXarz8iAnc5w3gAArC+g References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <20090403165143.GC1500@Sun.COM> From: "Santosh Chokhani" To: "Nicolas Williams" , "Russ Housley" Cc: labeled-nfs@linux-nfs.org, nfs-discuss@opensolaris.org, saag@ietf.org, selinux@tycho.nsa.gov, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:43:14 -0000 I am hoping that SPIF labeling in this community will either not be a problem or if it is part of the labeling and MAC policy, SPIF is not the only mechanism that is exacerbating it.=20 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Friday, April 03, 2009 12:52 PM > To: Russ Housley > Cc: Santosh Chokhani; saag@ietf.org;=20 > labeled-nfs@linux-nfs.org; selinux@tycho.nsa.gov;=20 > nfsv4@ietf.org; nfs-discuss@opensolaris.org > Subject: Re: [saag] Common labeled security (comment on=20 > CALIPSO, labeled NFSv4) >=20 > On Fri, Apr 03, 2009 at 12:44:30PM -0400, Russ Housley wrote: > > I really do not have time to write about all of my=20 > concerns. However,=20 > > once you get beyond the basic classifications, the SPIF=20 > model breaks. =20 > > They are markings that are only to be known to people that have the=20 > > clearance for those markings, this leads to a SPIF distribution=20 > > nightmare, as a subset of the real SPIF must be given out based on=20 > > access (or not) to various compartments and such. It just does not=20 > > scale. >=20 > I'm aware of the fact that labels can themselves be labeled. =20 > But I don't think that implies that we can't make a SPIF-like=20 > solution scale. >=20 > Peers that have access to different subsets of the policy=20 > should still be able to interop if care is taken to specify=20 > what happens when a node sees a label that falls outside its=20 > policy subset, and provided, of course, that the peers can=20 > agree that they have subsets of the *same* master policy. =20 > Peers can check whether they do have subsets of the > *same* master policy by exchanging [for each DOI to both] a=20 > master policy URI that includes a version number. >=20 > Nico > --=20 >=20 From SChokhani@cygnacom.com Fri Apr 3 11:10:26 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEAE93A67EC for ; Fri, 3 Apr 2009 11:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 UY07ERRyKwf6 for ; Fri, 3 Apr 2009 11:10:26 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id EB9C83A6939 for ; Fri, 3 Apr 2009 11:10:25 -0700 (PDT) Received: (qmail 9655 invoked from network); 3 Apr 2009 18:10:21 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 3 Apr 2009 18:10:21 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 14:11:27 -0400 Message-ID: In-Reply-To: <20090403173655.GK1500@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm0hzod+EbnZW7mT5uHCv4OgEisjAAAD3Tw References: <20090402154402.GM1500@Sun.COM> <20090403154253.GZ1500@Sun.COM> <20090403173655.GK1500@Sun.COM> From: "Santosh Chokhani" To: "Nicolas Williams" Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, saag@ietf.org, nfs-discuss@opensolaris.org, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:10:27 -0000 I do not know what the ISO spec has in it and how it relates to SPIF work we did.=20 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Friday, April 03, 2009 1:37 PM > To: Santosh Chokhani > Cc: saag@ietf.org; labeled-nfs@linux-nfs.org;=20 > nfs-discuss@opensolaris.org; nfsv4@ietf.org; selinux@tycho.nsa.gov > Subject: Re: [saag] Common labeled security (comment on=20 > CALIPSO, labeled NFSv4) >=20 > On Fri, Apr 03, 2009 at 01:34:23PM -0400, Santosh Chokhani wrote: > > The work I am mentioning was done for NSA and can be=20 > released if NSA=20 > > is ok with it. > >=20 > > I suspect NSA will be ok with it.=20 >=20 > Great! >=20 > But I was referring to the ISO15816 spec -- that does not=20 > belong to the NSA, though the NSA might be able to pull=20 > strings to make it a free spec. It took so long to make the=20 > ASN.1 specs free that I wouldn't hold my breath. I may be=20 > better for the IETF to start over on a replacement for SPIF. >=20 > Nico > --=20 >=20 From Nicolas.Williams@sun.com Fri Apr 3 11:15:16 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BDD3A6939; Fri, 3 Apr 2009 11:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 JOtabBYu32V0; Fri, 3 Apr 2009 11:15:15 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id B38F53A67EC; Fri, 3 Apr 2009 11:15:10 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n33IGDSA006451; Fri, 3 Apr 2009 18:16:13 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n33IGDDQ060664; Fri, 3 Apr 2009 12:16:13 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33HaujQ003042; Fri, 3 Apr 2009 12:36:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33HatnX003041; Fri, 3 Apr 2009 12:36:55 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 3 Apr 2009 12:36:55 -0500 From: Nicolas Williams To: Santosh Chokhani Message-ID: <20090403173655.GK1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> <20090403154253.GZ1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, saag@ietf.org, nfs-discuss@opensolaris.org, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:15:16 -0000 On Fri, Apr 03, 2009 at 01:34:23PM -0400, Santosh Chokhani wrote: > The work I am mentioning was done for NSA and can be released if NSA is > ok with it. > > I suspect NSA will be ok with it. Great! But I was referring to the ISO15816 spec -- that does not belong to the NSA, though the NSA might be able to pull strings to make it a free spec. It took so long to make the ASN.1 specs free that I wouldn't hold my breath. I may be better for the IETF to start over on a replacement for SPIF. Nico -- From SChokhani@cygnacom.com Fri Apr 3 12:50:45 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFD23A6452 for ; Fri, 3 Apr 2009 12:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 5JsdVDDvIJGd for ; Fri, 3 Apr 2009 12:50:44 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 9B97B3A6891 for ; Fri, 3 Apr 2009 12:50:44 -0700 (PDT) Received: (qmail 10504 invoked from network); 3 Apr 2009 19:50:40 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 3 Apr 2009 19:50:40 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 15:51:46 -0400 Message-ID: In-Reply-To: <20090403191838.GM1500@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm0lXBqRL4VRcenTUe1j+L/XDC9TQAABlOw References: <20090402154402.GM1500@Sun.COM> <20090403154253.GZ1500@Sun.COM> <20090403173655.GK1500@Sun.COM> <20090403191838.GM1500@Sun.COM> From: "Santosh Chokhani" To: "Nicolas Williams" Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, saag@ietf.org, nfs-discuss@opensolaris.org, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 19:50:45 -0000 NSA document on SPIF also had ASN.1 module for SPIF. May be you can use the applicable concepts to get a head start on XML.=20 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Friday, April 03, 2009 3:19 PM > To: Santosh Chokhani > Cc: saag@ietf.org; labeled-nfs@linux-nfs.org;=20 > nfs-discuss@opensolaris.org; nfsv4@ietf.org; selinux@tycho.nsa.gov > Subject: Re: [saag] Common labeled security (comment on=20 > CALIPSO, labeled NFSv4) >=20 > On Fri, Apr 03, 2009 at 02:11:27PM -0400, Santosh Chokhani wrote: > > I do not know what the ISO spec has in it and how it=20 > relates to SPIF=20 > > work we did. >=20 > It defines the ASN.1 module that you need to code to. >=20 From Nicolas.Williams@sun.com Fri Apr 3 12:56:54 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59313A696F; Fri, 3 Apr 2009 12:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.808 X-Spam-Level: X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Giixw1Y285XH; Fri, 3 Apr 2009 12:56:54 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 9DA1F3A68BF; Fri, 3 Apr 2009 12:56:53 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n33JvuDt023528; Fri, 3 Apr 2009 19:57:56 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n33JvuDW001277; Fri, 3 Apr 2009 13:57:56 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33JId9j003104; Fri, 3 Apr 2009 14:18:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33JIcs9003103; Fri, 3 Apr 2009 14:18:38 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 3 Apr 2009 14:18:38 -0500 From: Nicolas Williams To: Santosh Chokhani Message-ID: <20090403191838.GM1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> <20090403154253.GZ1500@Sun.COM> <20090403173655.GK1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, saag@ietf.org, nfs-discuss@opensolaris.org, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 19:56:54 -0000 On Fri, Apr 03, 2009 at 02:11:27PM -0400, Santosh Chokhani wrote: > I do not know what the ISO spec has in it and how it relates to SPIF > work we did. It defines the ASN.1 module that you need to code to. From Nicolas.Williams@sun.com Fri Apr 3 13:35:19 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58393A6452; Fri, 3 Apr 2009 13:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 FF4ffJiRYccL; Fri, 3 Apr 2009 13:35:19 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 2FCCC3A6810; Fri, 3 Apr 2009 13:35:19 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n33KaMa7013022; Fri, 3 Apr 2009 20:36:22 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n33KaL4V062873; Fri, 3 Apr 2009 14:36:22 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33Jv5Z1003276; Fri, 3 Apr 2009 14:57:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33Jv5d3003275; Fri, 3 Apr 2009 14:57:05 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 3 Apr 2009 14:57:05 -0500 From: Nicolas Williams To: Santosh Chokhani Message-ID: <20090403195704.GT1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> <20090403154253.GZ1500@Sun.COM> <20090403173655.GK1500@Sun.COM> <20090403191838.GM1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, saag@ietf.org, nfs-discuss@opensolaris.org, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:35:20 -0000 On Fri, Apr 03, 2009 at 03:51:46PM -0400, Santosh Chokhani wrote: > NSA document on SPIF also had ASN.1 module for SPIF. Ah, good! A link would be great. > May be you can use the applicable concepts to get a head start on XML. If the ASN.1 module can be obtained freely then the XML follows trivially (and, as I said, has already been done). From Kurt.Zeilenga@Isode.com Sat Apr 4 11:43:28 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4153A685B; Sat, 4 Apr 2009 11:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.08 X-Spam-Level: X-Spam-Status: No, score=-3.08 tagged_above=-999 required=5 tests=[AWL=-0.481, 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 hUbyNVrJ9peS; Sat, 4 Apr 2009 11:43:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 655733A6891; Sat, 4 Apr 2009 11:43:27 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 4 Apr 2009 19:44:30 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> From: Kurt Zeilenga To: Russ Housley In-Reply-To: <20090403164522.DEA9A9A4739@odin.smetech.net> Date: Sat, 4 Apr 2009 11:44:24 -0700 References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> X-Mailer: Apple Mail (2.930.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: selinux@tycho.nsa.gov, labeled-nfs@linux-nfs.org, nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Santosh Chokhani Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 18:43:28 -0000 On Apr 3, 2009, at 9:44 AM, Russ Housley wrote: > I really do not have time to write about all of my concerns. Understand. It might be a long write-up! > However, once you get beyond the basic classifications, the SPIF > model breaks. I would say that the SPIF model discussed in SDN 801 has some significant limitations. Dealing with the "black project" problem you allude to is certainly one of them. Another is that the SPIF only describes authorization to access (e.g., read) an object (given the policy, the object's label, and the accessor's clearance). It doesn't describes what labels an entity is allowed to use in labeling an object. While one might assume that "right to read" implies a "right to label", this assumption is only useful in simple environments. It cannot handle various national or international policies. I do think there is a need to develop a SPIF replacement that addresses various limitations, and would be willing to provide input in such an effort. However, it needs to be driven by key stakeholders. Until there is a suitable SPIF replacement for labeling at the application level (e.g., Directory, email, XMPP), I'll continue to implement SPIF-based solutions as simply there simply ain't anything better policy-neutral solution (that I'm aware of)... and that's what my customers are asking for (as they find it useful in their use cases). -- Kurt From housley@vigilsec.com Sat Apr 4 12:42:33 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FCFE3A6A79; Sat, 4 Apr 2009 12:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ooo17lTtUi6H; Sat, 4 Apr 2009 12:42:32 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id D61593A6A6D; Sat, 4 Apr 2009 12:42:31 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 3D18A9A474A; Sat, 4 Apr 2009 15:43:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id n-2faaXGMRzP; Sat, 4 Apr 2009 15:43:33 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-71-191-197-15.washdc.fios.verizon.net [71.191.197.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D08B89A473A; Sat, 4 Apr 2009 15:43:42 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 04 Apr 2009 14:39:29 -0400 To: "Santosh Chokhani" , From: Russ Housley In-Reply-To: References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090404194342.D08B89A473A@odin.smetech.net> Cc: labeled-nfs@linux-nfs.org, nfsv4@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 19:42:33 -0000 Santosh: There may be things that can be kept for this environment, especially if all of the clients of a particular file system are probably operating under a single security policy. If you can eliminate policy mapping and markings that must be hidden from some clients, then a subset of the SPIF may be useful. Russ At 01:36 PM 4/3/2009, Santosh Chokhani wrote: >Russ, > >My thinking was that the features of SPIF that are not needed could be >discarded. > >I was hoping that we could help the group save the baby and throw out >the bath water. > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Friday, April 03, 2009 12:45 PM > > To: Santosh Chokhani; saag@ietf.org > > Cc: labeled-nfs@linux-nfs.org; nfs-discuss@opensolaris.org; > > nfsv4@ietf.org; selinux@tycho.nsa.gov > > Subject: Re: [saag] Common labeled security (comment on > > CALIPSO, labeled NFSv4) > > > > I really do not have time to write about all of my concerns. > > However, once you get beyond the basic classifications, the > > SPIF model breaks. They are markings that are only to be > > known to people that have the clearance for those markings, > > this leads to a SPIF distribution nightmare, as a subset of > > the real SPIF must be given out based on access (or not) to > > various compartments and such. It just does not scale. > > > > Russ > > > > At 11:22 AM 4/3/2009, Santosh Chokhani wrote: > > >As part of MISSI and DMS, in mid to late 90's we did work on > > something > > >called Security Policy Information File (SPIF). > > > > > >At high level SPIF entailed the following: > > > > > >1. It was ASN.1 based. > > >2. It permitted you to convert the machine representation to human > > >readable representation. > > >3. It permitted you to convert the human readable input to machine > > >representation. > > >4. It mapped labels (hierarchical sensitivity levels and > > >non-hierarchical categories) from one labeling policy to > > another (i.e., > > >establish equivalency mapping) 5. It allowed you to > > constrain labels > > >since for some policies, existence of a category may mean some > > >categories, levels, may be included and/or excluded. > > > > > >Different labeling policies were indicated by different policy OID. > > > > > >Some of the concept from that work may be applicable here. > > > > > > > -----Original Message----- > > > > From: saag-bounces@ietf.org > > [mailto:saag-bounces@ietf.org] On Behalf > > > > Of Nicolas Williams > > > > Sent: Thursday, April 02, 2009 11:44 AM > > > > To: saag@ietf.org > > > > Cc: labeled-nfs@linux-nfs.org; selinux@tycho.nsa.gov; > > > > nfsv4@ietf.org; nfs-discuss@opensolaris.org > > > > Subject: [saag] Common labeled security (comment on > > CALIPSO, labeled > > > > NFSv4) > > > > > > > > Over at the NFSv4 WG we've been having a discussion of a labeled > > > > NFSv4 proposal. [Note: NFSv4 WG and others cc'ed, > > > > Reply-To: set to SAAG.] > > > > > > > > An interop issue has arisen that we believe applies equally to > > > > CALIPSO (draft-stjohns-sipso-11.txt)and requires input > > from the IETF > > > > security area. > > > > > > > > The issue is: how do do nodes in a labeled > > network/application know > > > > if they agree on a common labeled security policy for a given DOI? > > > > > > > > Agreeing on a DOI is accomplished easily enough -- that's not an > > > > issue. > > > > Agreeing on what a given numeric sensitivity level or compartment > > > > bit means in a given DOI is quite another. > > > > Without a solution to this we're left with out-of-band agreement, > > > > which leaves interop in a lurch. > > > > > > > > I think we need a generic MLS and DTE labeled security policy > > > > document format that allows a DOI to define the names and numeric > > > > assignments of sensitivity levels, compartments, etcetera. > > > > > > > > We also need a way for nodes to agree that they have the > > same policy > > > > for a given DOI, or that they agree on a common subset of a DOI's > > > > policy. > > > > > > > > This last problem can be solved by use of a labeled > > security policy > > > > URI scheme that includes a version number (+ a requirement that > > > > changes be in the form of additions and obsolescence of old > > > > assignments, but not removals). > > > > > > > > To recap: I think we need a) a common MLS and DTE labeled > > security > > > > policy document format, b) a labeled security policy URI > > scheme to > > > > refer to such documents by. > > > > > > > > Given (a) and (b) NFSv4.x clients and servers would only have to > > > > exchange {DOI #, policy URI} tuples to determine whether > > they agree > > > > on a common policy. > > > > > > > > Note that CALIPSO describes how to encode and compare MLS > > labels on > > > > the wire, but it does not describe how nodes agree on the > > meaning of > > > > particular sensitivity levels or compartments. Therefore > > CALIPSO is > > > > going to have much the same problem as NFSv4. > > > > > > > > Nico > > > > -- > > > > _______________________________________________ > > > > saag mailing list > > > > saag@ietf.org > > > > https://www.ietf.org/mailman/listinfo/saag > > > > > > >_______________________________________________ > > >saag mailing list > > >saag@ietf.org > > >https://www.ietf.org/mailman/listinfo/saag > > > > From SChokhani@cygnacom.com Sat Apr 4 15:09:43 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833AF3A691F for ; Sat, 4 Apr 2009 15:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 NOZ4C4+dG9h7 for ; Sat, 4 Apr 2009 15:09:42 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 25B493A6A8C for ; Sat, 4 Apr 2009 15:09:41 -0700 (PDT) Received: (qmail 23113 invoked from network); 4 Apr 2009 22:09:36 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 4 Apr 2009 22:09:35 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 4 Apr 2009 18:10:42 -0400 Message-ID: In-Reply-To: <20090404194342.D08B89A473A@odin.smetech.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm1XaVlsUXALZZKRMm5TFWg/nS+LAAE2p9A References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <20090404194342.D08B89A473A@odin.smetech.net> From: "Santosh Chokhani" To: "Russ Housley" , Cc: labeled-nfs@linux-nfs.org, nfsv4@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 22:09:43 -0000 Russ, I was thinking along the same lines. More specifically, 1. They can use he feature that helps covert machine representation to human readable representation and vice versa. 2. I suspect the distribution nightmare you mentioned and Kurt seconded relates to label names being sensitive or aggregation of labels' names being sensitive. I hope this is not a problem in the environments they mention in the sense that SPIF can be classified such that all users can access it. 3. They probably do not need the excluded and required features (i.e., they do not need to worry about some labels in the lattice being semantically permitted). This will simplify SPIF a lot. 4. I am torn on the issue of mapping you mentioned. At a minimum SPIF can let them label the data for different labeling policies and do away with the mapping as you suggest. This may mean that subject may need authorizations spelled out in multiple policy domains. This approach will get rid of one of your key concerns about complexity of SPIF. Item 2 above hopefully addresses the other. > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: Saturday, April 04, 2009 2:39 PM > To: Santosh Chokhani; saag@ietf.org > Cc: labeled-nfs@linux-nfs.org; nfs-discuss@opensolaris.org;=20 > nfsv4@ietf.org > Subject: RE: [saag] Common labeled security (comment on=20 > CALIPSO, labeled NFSv4) >=20 > Santosh: >=20 > There may be things that can be kept for this environment,=20 > especially if all of the clients of a particular file system=20 > are probably operating under a single security policy. If=20 > you can eliminate policy mapping and markings that must be=20 > hidden from some clients, then a subset of the SPIF may be useful. >=20 > Russ >=20 > At 01:36 PM 4/3/2009, Santosh Chokhani wrote: > >Russ, > > > >My thinking was that the features of SPIF that are not=20 > needed could be=20 > >discarded. > > > >I was hoping that we could help the group save the baby and=20 > throw out=20 > >the bath water. > > > > > -----Original Message----- > > > From: Russ Housley [mailto:housley@vigilsec.com] > > > Sent: Friday, April 03, 2009 12:45 PM > > > To: Santosh Chokhani; saag@ietf.org > > > Cc: labeled-nfs@linux-nfs.org; nfs-discuss@opensolaris.org;=20 > > > nfsv4@ietf.org; selinux@tycho.nsa.gov > > > Subject: Re: [saag] Common labeled security (comment on CALIPSO,=20 > > > labeled NFSv4) > > > > > > I really do not have time to write about all of my concerns. > > > However, once you get beyond the basic classifications, the SPIF=20 > > > model breaks. They are markings that are only to be=20 > known to people=20 > > > that have the clearance for those markings, this leads to a SPIF=20 > > > distribution nightmare, as a subset of the real SPIF must=20 > be given=20 > > > out based on access (or not) to various compartments and=20 > such. It=20 > > > just does not scale. > > > > > > Russ > > > > > > At 11:22 AM 4/3/2009, Santosh Chokhani wrote: > > > >As part of MISSI and DMS, in mid to late 90's we did work on > > > something > > > >called Security Policy Information File (SPIF). > > > > > > > >At high level SPIF entailed the following: > > > > > > > >1. It was ASN.1 based. > > > >2. It permitted you to convert the machine=20 > representation to human=20 > > > >readable representation. > > > >3. It permitted you to convert the human readable input=20 > to machine=20 > > > >representation. > > > >4. It mapped labels (hierarchical sensitivity levels and=20 > > > >non-hierarchical categories) from one labeling policy to > > > another (i.e., > > > >establish equivalency mapping) 5. It allowed you to > > > constrain labels > > > >since for some policies, existence of a category may mean some=20 > > > >categories, levels, may be included and/or excluded. > > > > > > > >Different labeling policies were indicated by different=20 > policy OID. > > > > > > > >Some of the concept from that work may be applicable here. > > > > > > > > > -----Original Message----- > > > > > From: saag-bounces@ietf.org > > > [mailto:saag-bounces@ietf.org] On Behalf > > > > > Of Nicolas Williams > > > > > Sent: Thursday, April 02, 2009 11:44 AM > > > > > To: saag@ietf.org > > > > > Cc: labeled-nfs@linux-nfs.org; selinux@tycho.nsa.gov;=20 > > > > > nfsv4@ietf.org; nfs-discuss@opensolaris.org > > > > > Subject: [saag] Common labeled security (comment on > > > CALIPSO, labeled > > > > > NFSv4) > > > > > > > > > > Over at the NFSv4 WG we've been having a discussion=20 > of a labeled > > > > > NFSv4 proposal. [Note: NFSv4 WG and others cc'ed, > > > > > Reply-To: set to SAAG.] > > > > > > > > > > An interop issue has arisen that we believe applies=20 > equally to=20 > > > > > CALIPSO (draft-stjohns-sipso-11.txt)and requires input > > > from the IETF > > > > > security area. > > > > > > > > > > The issue is: how do do nodes in a labeled > > > network/application know > > > > > if they agree on a common labeled security policy for=20 > a given DOI? > > > > > > > > > > Agreeing on a DOI is accomplished easily enough --=20 > that's not an=20 > > > > > issue. > > > > > Agreeing on what a given numeric sensitivity level or=20 > > > > > compartment bit means in a given DOI is quite another. > > > > > Without a solution to this we're left with out-of-band=20 > > > > > agreement, which leaves interop in a lurch. > > > > > > > > > > I think we need a generic MLS and DTE labeled security policy=20 > > > > > document format that allows a DOI to define the names and=20 > > > > > numeric assignments of sensitivity levels,=20 > compartments, etcetera. > > > > > > > > > > We also need a way for nodes to agree that they have the > > > same policy > > > > > for a given DOI, or that they agree on a common subset of a=20 > > > > > DOI's policy. > > > > > > > > > > This last problem can be solved by use of a labeled > > > security policy > > > > > URI scheme that includes a version number (+ a=20 > requirement that=20 > > > > > changes be in the form of additions and obsolescence of old=20 > > > > > assignments, but not removals). > > > > > > > > > > To recap: I think we need a) a common MLS and DTE labeled > > > security > > > > > policy document format, b) a labeled security policy URI > > > scheme to > > > > > refer to such documents by. > > > > > > > > > > Given (a) and (b) NFSv4.x clients and servers would=20 > only have to=20 > > > > > exchange {DOI #, policy URI} tuples to determine whether > > > they agree > > > > > on a common policy. > > > > > > > > > > Note that CALIPSO describes how to encode and compare MLS > > > labels on > > > > > the wire, but it does not describe how nodes agree on the > > > meaning of > > > > > particular sensitivity levels or compartments. Therefore > > > CALIPSO is > > > > > going to have much the same problem as NFSv4. > > > > > > > > > > Nico > > > > > -- > > > > > _______________________________________________ > > > > > saag mailing list > > > > > saag@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/saag > > > > > > > > >_______________________________________________ > > > >saag mailing list > > > >saag@ietf.org > > > >https://www.ietf.org/mailman/listinfo/saag > > > > > > >=20 >=20 From SChokhani@cygnacom.com Sat Apr 4 15:52:18 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C973A68ED for ; Sat, 4 Apr 2009 15:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 A7rZ0TM-OjKK for ; Sat, 4 Apr 2009 15:52:18 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id CE26B3A6817 for ; Sat, 4 Apr 2009 15:52:17 -0700 (PDT) Received: (qmail 23331 invoked from network); 4 Apr 2009 22:45:32 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 4 Apr 2009 22:45:32 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 4 Apr 2009 18:46:39 -0400 Message-ID: In-Reply-To: <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm1VWWNXHfsNefAT7WpUuGq2cXHtgAHNrzQ References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> From: "Santosh Chokhani" To: "Kurt Zeilenga" , "Russ Housley" Cc: labeled-nfs@linux-nfs.org, nfs-discuss@opensolaris.org, saag@ietf.org, selinux@tycho.nsa.gov, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 22:52:18 -0000 Kurt, Thanks.=20 On the issue of authorization to "label" an object, I assume you are not saying that write authorizations need to be separate from read authorization. I suspect you are saying that since one may be providing information to multiple parties operating under different policies, one may need to label the information for each party. SDN series took care of this by providing the subject clearance in X.509 certificate in the subject's policy domain. These clearance checks are made during message creation. It is required that the SPIF in the recipient policy domain use the equivalency mapping to enforce the access control, just like the subject makes these checks in their domain. To illustrate, Let us say that subject A has clearance asserted in policy X and has a SPIF that specifies policy X and maps policy X to Y. Let us say that subject B has clearance asserted in policy Y and has a SPIF that specifies policy Y and maps policy Y to X. Now, under the reader to writer security model, the following should occur: 1. When A creates a message for B with label L, A's clearance under policy X to create label L can be checked. Also, B's clearance under Policy Y can be converted to equivalent under Policy X using SPIF X. Then, it can be determined if B is allowed to receive message with Label L. 2. B can do a mirror image of this when B receives the message. This approach also fits nicely with the traditional subject, subject clearance, object, object label, and MAC policy in the computer security world. Alternative means can be explored if SPIF equivalency is deemed overly complex. I hope once the alternative solutions are developed, their complexity and SPIF complexity due to equivalency will be compared to determine which solution is the best. > -----Original Message----- > From: Kurt Zeilenga [mailto:Kurt.Zeilenga@Isode.com]=20 > Sent: Saturday, April 04, 2009 2:44 PM > To: Russ Housley > Cc: Santosh Chokhani; saag@ietf.org;=20 > labeled-nfs@linux-nfs.org; selinux@tycho.nsa.gov;=20 > nfsv4@ietf.org; nfs-discuss@opensolaris.org > Subject: Re: [saag] Common labeled security (comment on=20 > CALIPSO, labeled NFSv4) >=20 >=20 > On Apr 3, 2009, at 9:44 AM, Russ Housley wrote: >=20 > > I really do not have time to write about all of my concerns. >=20 > Understand. It might be a long write-up! >=20 > > However, once you get beyond the basic classifications, the=20 > SPIF model=20 > > breaks. >=20 > I would say that the SPIF model discussed in SDN 801 has some=20 > significant limitations. Dealing with the "black project"=20 > problem you allude to is certainly one of them. Another is=20 > that the SPIF only describes authorization to access (e.g.,=20 > read) an object (given the policy, the object's label, and=20 > the accessor's clearance). It doesn't describes what labels=20 > an entity is allowed to use in labeling an object. While one=20 > might assume that "right to read" implies a "right to label",=20 > this assumption is only useful in simple environments. It=20 > cannot handle various national or international policies. >=20 > I do think there is a need to develop a SPIF replacement that=20 > addresses various limitations, and would be willing to=20 > provide input in such an effort. However, it needs to be=20 > driven by key stakeholders. >=20 > Until there is a suitable SPIF replacement for labeling at=20 > the application level (e.g., Directory, email, XMPP), I'll=20 > continue to implement SPIF-based solutions as simply there=20 > simply ain't anything better policy-neutral solution (that=20 > I'm aware of)... and that's what my customers are asking for=20 > (as they find it useful in their use cases). >=20 > -- Kurt >=20 From Kurt.Zeilenga@Isode.com Sat Apr 4 15:59:39 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D713A6903; Sat, 4 Apr 2009 15:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.984 X-Spam-Level: X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=-0.385, 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 CaTHAPXIRgHA; Sat, 4 Apr 2009 15:59:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A81D33A6891; Sat, 4 Apr 2009 15:59:38 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 5 Apr 2009 00:00:41 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: From: Kurt Zeilenga To: Santosh Chokhani In-Reply-To: Date: Sat, 4 Apr 2009 16:00:36 -0700 References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> X-Mailer: Apple Mail (2.930.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: selinux@tycho.nsa.gov, labeled-nfs@linux-nfs.org, nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 22:59:39 -0000 On Apr 4, 2009, at 3:46 PM, Santosh Chokhani wrote: > On the issue of authorization to "label" an object, I assume you are > not > saying that write authorizations need to be separate from read > authorization. No, I am saying the lack of separate "to read"/"to label" authorizations is a significant limitation of the SDN SPIF model. For instance, one might not require any particular clearance to read UNCLASSIFIED//RELEASEABLE-TO-PUBLIC under a particular policy, but under that policy one might be required a specific clearance to create an object with a UNCLASSIFIED//RELEASEABLE-TO-PUBLIC label. (There are a number of real world national/international policies that have asymmetric "to read"/"to label" handling of security labels.) The SDN SPIF model, unfortunately, assumes that authorization to read implies authorization to label, so one cannot represent such a policy in a SPIF. -- Kurt From turners@ieca.com Sat Apr 4 18:33:44 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43273A69D3 for ; Sat, 4 Apr 2009 18:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 9IKS7Ivi5Kgy for ; Sat, 4 Apr 2009 18:33:44 -0700 (PDT) Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by core3.amsl.com (Postfix) with SMTP id 72F9C3A69A1 for ; Sat, 4 Apr 2009 18:33:44 -0700 (PDT) Received: (qmail 7449 invoked from network); 5 Apr 2009 01:28:07 -0000 Received: from unknown (HELO sean-turners-macbook.local) (turners@96.231.127.114 with plain) by smtp103.biz.mail.re2.yahoo.com with SMTP; 5 Apr 2009 01:28:06 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: 4EMMffAVM1m9gDbmkuI2vcIlO5cP6zFIHh5nu5Ib1aDZ0aSIDhLnNrqU_GOQD9kmWSsWdr.63QxHwtX9oLZA7iPvICICjmB3hTikl_VQU.OV806jpwp_3293FG7o9FHWeKSRANYPJ3sMHA0NgrCwc_05A5MDoErcYkU3e_f1Vyhht.qHZsM5_vSZK_45Eygeri7.iR1X810YdHGYxGL15HWnFdS1IqAFAR3PL5Tvrsa.d2zTXVhZCHed.TOkhTw95xRQfzUg8upoW4j73GuER0oRZF1DRcfrJZ5zrQcvR9x5fSolywNzQdi0Vt3HT4W4VmKwB5f85gEIbGRj71E- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D80922.9050700@ieca.com> Date: Sat, 04 Apr 2009 21:28:02 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicolas Williams References: <20090402154402.GM1500@Sun.COM> <20090403154253.GZ1500@Sun.COM> <20090403173655.GK1500@Sun.COM> <20090403191838.GM1500@Sun.COM> <20090403195704.GT1500@Sun.COM> In-Reply-To: <20090403195704.GT1500@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: selinux@tycho.nsa.gov, labeled-nfs@linux-nfs.org, nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Santosh Chokhani Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 01:33:44 -0000 Nico, I usually try to find the corresponding ITU spec because I think ITU gives out all of it's ASN.1 modules freely? Anyway, here's a link to the ITU-T X.841 Spec: http://www.itu.int/ITU-T/asn1/database/itu-t/x/x841/2000/index.html The one thing that's missing from the module is definitions for security categories. Some suggested categories were defined in Annex B, but it's an informative annex so there's no ASN.1 freely available (they wouldn't allow them in the normative text/module). Those categories are based on FIPS 188 (the syntax is not the same). Note that some of the syntax for labels has made it's way to some IDs/RFCs notably RFC 2634. spt Nicolas Williams wrote: > On Fri, Apr 03, 2009 at 03:51:46PM -0400, Santosh Chokhani wrote: >> NSA document on SPIF also had ASN.1 module for SPIF. > > Ah, good! A link would be great. > >> May be you can use the applicable concepts to get a head start on XML. > > If the ASN.1 module can be obtained freely then the XML follows > trivially (and, as I said, has already been done). > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From SChokhani@cygnacom.com Sun Apr 5 05:00:07 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F178E3A69D4 for ; Sun, 5 Apr 2009 05:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 dNe1CYBhiS6P for ; Sun, 5 Apr 2009 05:00:06 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id D93833A6A24 for ; Sun, 5 Apr 2009 05:00:05 -0700 (PDT) Received: (qmail 1630 invoked from network); 5 Apr 2009 11:59:58 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 5 Apr 2009 11:59:58 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 5 Apr 2009 08:01:06 -0400 Message-ID: In-Reply-To: <49D80922.9050700@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm1jcbIy9cgJJFWTUG5/g5z6pt3owAWCHaw References: <20090402154402.GM1500@Sun.COM> <20090403154253.GZ1500@Sun.COM> <20090403173655.GK1500@Sun.COM> <20090403191838.GM1500@Sun.COM> <20090403195704.GT1500@Sun.COM> <49D80922.9050700@ieca.com> From: "Santosh Chokhani" To: "Sean Turner" , "Nicolas Williams" Cc: labeled-nfs@linux-nfs.org, nfs-discuss@opensolaris.org, saag@ietf.org, selinux@tycho.nsa.gov, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 12:00:07 -0000 Nico, The link provided by Sean should help you quite a bit. The main module leaves up to you to define the semantics of categories and their interactions. (May be this is consistent with what Russ is saying about categories adding excessive complexity) I did not look at other modules to see if they define categories any further.=20 > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com]=20 > Sent: Saturday, April 04, 2009 9:28 PM > To: Nicolas Williams > Cc: Santosh Chokhani; labeled-nfs@linux-nfs.org;=20 > selinux@tycho.nsa.gov; saag@ietf.org;=20 > nfs-discuss@opensolaris.org; nfsv4@ietf.org > Subject: Re: [saag] Common labeled security (comment on=20 > CALIPSO, labeled NFSv4) >=20 > Nico, >=20 > I usually try to find the corresponding ITU spec because I=20 > think ITU gives out all of it's ASN.1 modules freely? =20 > Anyway, here's a link to the ITU-T X.841 Spec: > http://www.itu.int/ITU-T/asn1/database/itu-t/x/x841/2000/index.html >=20 > The one thing that's missing from the module is definitions=20 > for security categories. Some suggested categories were=20 > defined in Annex B, but it's an informative annex so there's=20 > no ASN.1 freely available (they wouldn't allow them in the=20 > normative text/module). Those categories are based on FIPS=20 > 188 (the syntax is not the same). >=20 > Note that some of the syntax for labels has made it's way to=20 > some IDs/RFCs notably RFC 2634. >=20 > spt >=20 > Nicolas Williams wrote: > > On Fri, Apr 03, 2009 at 03:51:46PM -0400, Santosh Chokhani wrote: > >> NSA document on SPIF also had ASN.1 module for SPIF. > >=20 > > Ah, good! A link would be great. > >=20 > >> May be you can use the applicable concepts to get a head=20 > start on XML.=20 > >=20 > > If the ASN.1 module can be obtained freely then the XML follows=20 > > trivially (and, as I said, has already been done). > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > >=20 >=20 From Pasi.Eronen@nokia.com Mon Apr 6 02:53:46 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD8628C135 for ; Mon, 6 Apr 2009 02:53:46 -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 aKv0AK2dBUr7 for ; Mon, 6 Apr 2009 02:53:45 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 2262528C140 for ; Mon, 6 Apr 2009 02:53:44 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n369rNJd022389 for ; Mon, 6 Apr 2009 04:54:49 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 12:53:45 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 12:53:45 +0300 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 6 Apr 2009 11:53:45 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Mon, 6 Apr 2009 11:53:45 +0200 From: To: Date: Mon, 6 Apr 2009 11:53:45 +0200 Thread-Topic: IETF74 SAAG draft minutes Thread-Index: Acm2nZNWYmw7cCNSRM+E2iyS0htn4A== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F22148ED@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Apr 2009 09:53:45.0516 (UTC) FILETIME=[935BD6C0:01C9B69D] X-Nokia-AV: Clean Subject: [saag] IETF74 SAAG draft minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 09:53:46 -0000 I've uploaded the draft minutes from SAAG here:=20 http://www.ietf.org/proceedings/09mar/minutes/saag.txt Please send any corrections/additions to me and Tim. (And big=20 thanks to Jeffrey Hutzelman and Tero Kivinen for taking notes!) Best regards, Pasi= From SChokhani@cygnacom.com Mon Apr 6 04:02:29 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D428728C12A for ; Mon, 6 Apr 2009 04:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 8SMbw86n7PW2 for ; Mon, 6 Apr 2009 04:02:29 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id F05B828C126 for ; Mon, 6 Apr 2009 04:02:28 -0700 (PDT) Received: (qmail 12373 invoked from network); 6 Apr 2009 11:02:24 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Apr 2009 11:02:24 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 07:03:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm1eS9jLv/W1lPHShC3bzOQCp9dFABLaj8Q References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> From: "Santosh Chokhani" To: "Kurt Zeilenga" Cc: selinux@tycho.nsa.gov, labeled-nfs@linux-nfs.org, nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 11:02:29 -0000 Kurt, Good point. This capability should not impact SPIF. The capability to read Vs. assert should impact the clearance structure and the companion access control decision function. I view SPIF as performing the following functions: converting machine to human representation and vice versa; establishing equivalency between two labeling policies, and defining which labels with the lattice are valid and which are invalid. > -----Original Message----- > From: Kurt Zeilenga [mailto:Kurt.Zeilenga@Isode.com]=20 > Sent: Saturday, April 04, 2009 7:01 PM > To: Santosh Chokhani > Cc: Russ Housley; saag@ietf.org; labeled-nfs@linux-nfs.org;=20 > selinux@tycho.nsa.gov; nfsv4@ietf.org; nfs-discuss@opensolaris.org > Subject: Re: [saag] Common labeled security (comment on=20 > CALIPSO, labeled NFSv4) >=20 >=20 > On Apr 4, 2009, at 3:46 PM, Santosh Chokhani wrote: > > On the issue of authorization to "label" an object, I=20 > assume you are=20 > > not saying that write authorizations need to be separate from read=20 > > authorization. >=20 > No, I am saying the lack of separate "to read"/"to label" =20 > authorizations is a significant limitation of the SDN SPIF=20 > model. For instance, one might not require any particular=20 > clearance to read UNCLASSIFIED//RELEASEABLE-TO-PUBLIC under a=20 > particular policy, but under that policy one might be=20 > required a specific clearance to create an object with a=20 > UNCLASSIFIED//RELEASEABLE-TO-PUBLIC label. (There are a=20 > number of real world national/international policies that=20 > have asymmetric "to read"/"to label" handling of security=20 > labels.) The SDN SPIF model, unfortunately, assumes that=20 > authorization to read implies authorization to label, so one=20 > cannot represent such a policy in a SPIF. >=20 > -- Kurt >=20 From benl@google.com Mon Apr 6 06:07:59 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9471328C164 for ; Mon, 6 Apr 2009 06:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 AVAvbPThAPpC for ; Mon, 6 Apr 2009 06:07:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 1758C3A6C20 for ; Mon, 6 Apr 2009 06:07:51 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id n36D8uHB032691 for ; Mon, 6 Apr 2009 14:08:56 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1239023336; bh=wnK4DsD6y/na9wHWwm0LDr6EuJY=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=ghzncHaD5p5oUM4fB8 zst8OsSRGRWEtiCm5uQu9qeOGnUGchfud+e1iUTZsyfZ4R/F1yr1QhhOsUuQxjNhLo9 A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=J/K5EewH1Qy3/h0L/x41AbftY23wOf2N82TOyebVoGEvh0d/xmtpjNoWbcRpxDEuq ar3gbk3l8l/VFFGjwn+rA== Received: from fg-out-1718.google.com (fge13.prod.google.com [10.86.5.13]) by wpaz21.hot.corp.google.com with ESMTP id n36D8skY010260 for ; Mon, 6 Apr 2009 06:08:54 -0700 Received: by fg-out-1718.google.com with SMTP id 13so678503fge.12 for ; Mon, 06 Apr 2009 06:08:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.82.16 with SMTP id f16mr3195089fgb.32.1239023333820; Mon, 06 Apr 2009 06:08:53 -0700 (PDT) In-Reply-To: References: <120077F4-0B65-4032-B5A2-FA8FA1330695@nokia.com> Date: Mon, 6 Apr 2009 14:08:53 +0100 Message-ID: <1b587cab0904060608x14ccee52g2d16c4e780f8cd5@mail.gmail.com> From: Ben Laurie To: Thomas Roessler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Arthur Barstow , saag@ietf.org, Frederick Hirsch Subject: Re: [saag] Fwd: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 13:07:59 -0000 2009/4/2 Thomas Roessler : > FYI. > Note that the document is referencing an upcoming version of XML Signatur= e, > which is currently in Working Draft status. > There is an expectation that this profile (not the base spec) might under= go > a W3C last call relatively soon, so this would be a good time to review t= he > specification. I find it pretty annoying that signing widgets is described as a "trust and quality assurance mechanism". > -- > Thomas Roessler, W3C =A0 > > > > > > Begin forwarded message: > > From: Arthur Barstow > Date: 2 April 2009 18:21:19 GMT+02:00 > To: public-webapps > Subject: [widgets] New WD of Widgets 1.0: Digital Signatures spec publish= ed > on March 31 > Archived-At: > > On March 31 a new WD of the Widgets 1.0 Digital Signature spec was publis= hed > and announced on the W3C's home page: > > [[ > 2009-03-31: The Web Applications Working Group has published a Working Dr= aft > of Widgets 1.0: Digital Signatures. This document defines a profile of th= e > XML Signature Syntax and Processing 1.1 specification to allow a widget > package to be digitally signed. Widget authors and distributors can > digitally sign widgets as a trust and quality assurance mechanism. Prior = to > instantiation, a user agent can use the digital signature to verify the > integrity of the widget package and perform source authentication. This > document specifies conformance requirements on both widget packages and u= ser > agents. > ]] > > Please review this new WD as soon as possible, preferably within the next > two weeks: > > > > -Regards, Art Barstow > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From pgut001@cs.auckland.ac.nz Mon Apr 6 06:46:40 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED27A28C158 for ; Mon, 6 Apr 2009 06:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CC1ZEij1v22n for ; Mon, 6 Apr 2009 06:46:34 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id EF3F83A698F for ; Mon, 6 Apr 2009 06:46:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A1E039F2BE; Tue, 7 Apr 2009 01:47:36 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2mdHGh8nCi4; Tue, 7 Apr 2009 01:47:36 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5610C9F2B7; Tue, 7 Apr 2009 01:47:36 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 637171DE4001; Tue, 7 Apr 2009 01:47:35 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LqpAl-0000em-7S; Tue, 07 Apr 2009 01:47:35 +1200 From: Peter Gutmann To: benl@google.com, tlr@w3.org In-Reply-To: <1b587cab0904060608x14ccee52g2d16c4e780f8cd5@mail.gmail.com> Message-Id: Sender: pgut001 Date: Tue, 07 Apr 2009 01:47:35 +1200 Cc: art.barstow@nokia.com, Frederick.Hirsch@nokia.com, saag@ietf.org Subject: Re: [saag] Fwd: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 13:46:41 -0000 Ben Laurie writes: >I find it pretty annoying that signing widgets is described as a "trust and >quality assurance mechanism". It's a valid comment though. A large-scale study (from Microsoft's malware research group) has shown that the majority of CA-certified signed malware is in the "severe" or "high-risk" category. So seeing a signature on malware provides a high level of trust that this is the high-quality stuff you're seeing and not some cheap knockoff. Peter. From benl@google.com Mon Apr 6 07:14:03 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75773A6CA1 for ; Mon, 6 Apr 2009 07:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 GLcL9CSeEq3k for ; Mon, 6 Apr 2009 07:13:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id BC8B53A6CAB for ; Mon, 6 Apr 2009 07:13:53 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id n36EEv64031931 for ; Mon, 6 Apr 2009 15:14:57 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1239027298; bh=t4FcGrEFQDB38O+g+3VufJqg+Ik=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=EVXCuiF99R803tVz5v vdwTd96zg5iI1VFQyn9b5e9MW7x0yrA4m7t0mnIcEt/QPTXkWTKgvqZWyMBHPxAd91+ w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=DWlGLFS4sfGqtotGZAPwuGlehm2ETlf+2Rr/Qel2KCtex5CoPCoI1MAarrawq5Fek FQCd7zJEUpibiImAVLudw== Received: from fxm9 (fxm9.prod.google.com [10.184.13.9]) by wpaz29.hot.corp.google.com with ESMTP id n36EEtZM028487 for ; Mon, 6 Apr 2009 07:14:56 -0700 Received: by fxm9 with SMTP id 9so2338762fxm.35 for ; Mon, 06 Apr 2009 07:14:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.33.10 with SMTP id g10mr3304498fgg.47.1239027294905; Mon, 06 Apr 2009 07:14:54 -0700 (PDT) In-Reply-To: References: <1b587cab0904060608x14ccee52g2d16c4e780f8cd5@mail.gmail.com> Date: Mon, 6 Apr 2009 15:14:54 +0100 Message-ID: <1b587cab0904060714h4deb48b2of69d0252988be2f5@mail.gmail.com> From: Ben Laurie To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: art.barstow@nokia.com, Frederick.Hirsch@nokia.com, saag@ietf.org Subject: Re: [saag] Fwd: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 14:14:03 -0000 On Mon, Apr 6, 2009 at 2:47 PM, Peter Gutmann w= rote: > Ben Laurie writes: > >>I find it pretty annoying that signing widgets is described as a "trust a= nd >>quality assurance mechanism". > > It's a valid comment though. =A0A large-scale study (from Microsoft's mal= ware > research group) has shown that the majority of CA-certified signed malwar= e is > in the "severe" or "high-risk" category. =A0So seeing a signature on malw= are > provides a high level of trust that this is the high-quality stuff you're > seeing and not some cheap knockoff. Awesome! Link? > > Peter. > > From pgut001@cs.auckland.ac.nz Mon Apr 6 08:08:00 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A6728C1EF for ; Mon, 6 Apr 2009 08:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.008 X-Spam-Level: X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=0.591, 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 bjgEodIN5e4x for ; Mon, 6 Apr 2009 08:07:59 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 6615D28C230 for ; Mon, 6 Apr 2009 08:06:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 67909481AFC; Tue, 7 Apr 2009 03:07:24 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iylXS6pBu5is; Tue, 7 Apr 2009 03:07:24 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 30AB2481AF3; Tue, 7 Apr 2009 03:07:23 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 7F8801DE4001; Tue, 7 Apr 2009 03:07:22 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LqqPy-0004YB-AP; Tue, 07 Apr 2009 03:07:22 +1200 From: Peter Gutmann To: benl@google.com, pgut001@cs.auckland.ac.nz In-Reply-To: <1b587cab0904060714h4deb48b2of69d0252988be2f5@mail.gmail.com> Message-Id: Sender: pgut001 Date: Tue, 07 Apr 2009 03:07:22 +1200 Cc: art.barstow@nokia.com, Frederick.Hirsch@nokia.com, saag@ietf.org Subject: Re: [saag] Fwd: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 15:08:00 -0000 Ben Laurie writes: >On Mon, Apr 6, 2009 at 2:47 PM, Peter Gutmann wrote: >> Ben Laurie writes: >>>I find it pretty annoying that signing widgets is described as a "trust and >>>quality assurance mechanism". >> >> It's a valid comment though. =A0A large-scale study (from Microsoft's malware >> research group) has shown that the majority of CA-certified signed malware is >> in the "severe" or "high-risk" category. =A0So seeing a signature on malware >> provides a high level of trust that this is the high-quality stuff you're >> seeing and not some cheap knockoff. > >Awesome! Link? http://blogs.technet.com/mmpc/archive/2008/11/06/malware-and-signed-code.aspx (this was what motivated my "Asking the drunk whether he's drunk" post on the cryptography list a few months back). As a general comment, signed malware has been out there for some years now, but this is the first large-scale (I mean seriously large-scale) study of it. 1.78M signed non-malicious files, 173K signed malware files, so one in ten signed files on a PC is genuine CA-certified signed malware (and that's a lower bound based on what's detectable by the MMPC scan, any decently-infected machine will have scanning disabled or subverted so it won't register). From the report: Of signed detected files, severity of the threats tended to be high or severe, with low and moderate threats comprising a much smaller number of files: Severe 50819 High 73677 Moderate 42308 Low 1099 So there you go, signing definitely does provide a "trust and quality assurance mechanism". If it's a CA-certified signed rootkit or worm, you know you've been infected by the good stuff. Peter. From SChokhani@cygnacom.com Mon Apr 6 08:50:41 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A843A68DE for ; Mon, 6 Apr 2009 08:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 4ZNntG45GCI5 for ; Mon, 6 Apr 2009 08:50:34 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 2894D28C1F2 for ; Mon, 6 Apr 2009 08:50:34 -0700 (PDT) Received: (qmail 14755 invoked from network); 6 Apr 2009 15:50:28 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Apr 2009 15:50:28 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 11:51:38 -0400 Message-ID: In-Reply-To: <20090406151606.GQ1500@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm2zw6I8dU/A2hTSWG5tuufhnf4TAAAD5QA References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> From: "Santosh Chokhani" To: "Nicolas Williams" Cc: selinux@tycho.nsa.gov, labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 15:50:41 -0000 Nico, Either you need equivalency or not. If you do not, that part of SPIF can be stripped off. If you do need one, the complexity, scalability, and interoperability of other alternatives should be assessed against SPIF approach. (We want to compare apples to apples)=20 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Monday, April 06, 2009 11:16 AM > To: Santosh Chokhani > Cc: Kurt Zeilenga; selinux@tycho.nsa.gov;=20 > labeled-nfs@linux-nfs.org; nfsv4@ietf.org; saag@ietf.org;=20 > nfs-discuss@opensolaris.org > Subject: Re: [saag] Common labeled security (comment on=20 > CALIPSO, labeled NFSv4) >=20 > On Mon, Apr 06, 2009 at 07:03:32AM -0400, Santosh Chokhani wrote: > > I view SPIF as performing the following functions:=20 > converting machine=20 > > to human representation and vice versa; establishing equivalency=20 > > between two labeling policies, and defining which labels with the=20 > > lattice are valid and which are invalid. >=20 > If I understand Russ' comment correctly the difficulty with=20 > SPIF lies in the label equivalency concept. I think there's=20 > a better solution for dealing with the idea that parts of a=20 > policy are classified differently than others. >=20 > Nico > --=20 >=20 From Nicolas.Williams@sun.com Mon Apr 6 08:54:26 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0E528C1FE; Mon, 6 Apr 2009 08:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 gREk+G-YYe9a; Mon, 6 Apr 2009 08:54:20 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id B82F328C19D; Mon, 6 Apr 2009 08:54:19 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n36FtPxm002484; Mon, 6 Apr 2009 15:55:25 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n36FtPgT040850; Mon, 6 Apr 2009 09:55:25 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n36FG70Q004441; Mon, 6 Apr 2009 10:16:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n36FG6qa004440; Mon, 6 Apr 2009 10:16:06 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 6 Apr 2009 10:16:06 -0500 From: Nicolas Williams To: Santosh Chokhani Message-ID: <20090406151606.GQ1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: selinux@tycho.nsa.gov, labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 15:54:26 -0000 On Mon, Apr 06, 2009 at 07:03:32AM -0400, Santosh Chokhani wrote: > I view SPIF as performing the following functions: converting machine to > human representation and vice versa; establishing equivalency between > two labeling policies, and defining which labels with the lattice are > valid and which are invalid. If I understand Russ' comment correctly the difficulty with SPIF lies in the label equivalency concept. I think there's a better solution for dealing with the idea that parts of a policy are classified differently than others. Nico -- From Nicolas.Williams@sun.com Mon Apr 6 09:13:06 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756073A6CF0; Mon, 6 Apr 2009 09:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 HPEt4fH6SJfe; Mon, 6 Apr 2009 09:13:00 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 25B7928C230; Mon, 6 Apr 2009 09:11:44 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n36GCoIo005536; Mon, 6 Apr 2009 16:12:50 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n36GCnXC057339; Mon, 6 Apr 2009 10:12:50 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n36FB2g8004433; Mon, 6 Apr 2009 10:11:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n36FB10N004432; Mon, 6 Apr 2009 10:11:01 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 6 Apr 2009 10:11:01 -0500 From: Nicolas Williams To: Sean Turner Message-ID: <20090406151100.GP1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> <20090403154253.GZ1500@Sun.COM> <20090403173655.GK1500@Sun.COM> <20090403191838.GM1500@Sun.COM> <20090403195704.GT1500@Sun.COM> <49D80922.9050700@ieca.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D80922.9050700@ieca.com> User-Agent: Mutt/1.5.7i Cc: selinux@tycho.nsa.gov, labeled-nfs@linux-nfs.org, nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Santosh Chokhani Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 16:13:06 -0000 On Sat, Apr 04, 2009 at 09:28:02PM -0400, Sean Turner wrote: > I usually try to find the corresponding ITU spec because I think ITU > gives out all of it's ASN.1 modules freely? Anyway, here's a link to > the ITU-T X.841 Spec: > http://www.itu.int/ITU-T/asn1/database/itu-t/x/x841/2000/index.html Thanks. I'm sure the spec needs to be read too, not just the ASN.1 module (it's mostly self-evident, but some types, like LabelAndCertValue, require an explanation). > The one thing that's missing from the module is definitions for security > categories. Some suggested categories were defined in Annex B, but it's > an informative annex so there's no ASN.1 freely available (they wouldn't > allow them in the normative text/module). Those categories are based on > FIPS 188 (the syntax is not the same). > > Note that some of the syntax for labels has made it's way to some > IDs/RFCs notably RFC 2634. Thanks. That's very useful. Nico -- From Nicolas.Williams@sun.com Mon Apr 6 10:00:40 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8682D3A6CDB; Mon, 6 Apr 2009 10:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 6VwAKV3DArst; Mon, 6 Apr 2009 10:00:39 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id C92893A6CB6; Mon, 6 Apr 2009 10:00:39 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n36H1j46013703; Mon, 6 Apr 2009 17:01:45 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n36H1jdF030595; Mon, 6 Apr 2009 11:01:45 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n36GMQAG004527; Mon, 6 Apr 2009 11:22:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n36GMQP1004526; Mon, 6 Apr 2009 11:22:26 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 6 Apr 2009 11:22:26 -0500 From: Nicolas Williams To: Santosh Chokhani Message-ID: <20090406162226.GX1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: selinux@tycho.nsa.gov, labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:00:40 -0000 On Mon, Apr 06, 2009 at 11:51:38AM -0400, Santosh Chokhani wrote: > Either you need equivalency or not. > > If you do not, that part of SPIF can be stripped off. > > If you do need one, the complexity, scalability, and interoperability of > other alternatives should be assessed against SPIF approach. Indeed. I think, however, that it will be necessary to support policies parts of which are classified differently from each other. It'd be nice to be able to get rid of such a complication. But you can see why this is needed. Remember that during WWII very few people on the Allied side knew about some of the cryptanalysis efforts being made, and, IIRC, all such information was classified as "Ultra" and no one who didn't have Ultra clearance was allowed to know that Ultra existed (presumably because public knowledge of such a classification might have caused the enemy to wonder). Today the names and existence of specific compartments rather than specific sensitivity level, are likley to be the cause of thie requirement. Nico -- From housley@vigilsec.com Mon Apr 6 11:33:52 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FAFC28C16F; Mon, 6 Apr 2009 11:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 vkdTtSiChka2; Mon, 6 Apr 2009 11:33:45 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 5730528C177; Mon, 6 Apr 2009 11:33:45 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 5645A9A471B; Mon, 6 Apr 2009 14:04:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 7Guj3qYdruEZ; Mon, 6 Apr 2009 14:04:07 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-71-191-197-15.washdc.fios.verizon.net [71.191.197.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BA7AC9A4749; Mon, 6 Apr 2009 14:04:24 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Apr 2009 13:50:32 -0400 To: Nicolas Williams , Santosh Chokhani From: Russ Housley In-Reply-To: <20090406151606.GQ1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090406180424.BA7AC9A4749@odin.smetech.net> Cc: saag@ietf.org, labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfs-discuss@opensolaris.org, nfsv4@ietf.org Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 18:33:52 -0000 Nico: >On Mon, Apr 06, 2009 at 07:03:32AM -0400, Santosh Chokhani wrote: > > I view SPIF as performing the following functions: converting machine to > > human representation and vice versa; establishing equivalency between > > two labeling policies, and defining which labels with the lattice are > > valid and which are invalid. > >If I understand Russ' comment correctly the difficulty with SPIF lies in >the label equivalency concept. I think there's a better solution for >dealing with the idea that parts of a policy are classified differently >than others. No. They are two separate concerns. Mapping labels between two different policies. Hopefully this can be avoided altogether in the NFS context. Some label values are not releasable to clients that do not have access to data associated with that label. This one is a real-world problem, and it leads to different clients having different subsets of the SPIF if this community that is being supported has this requirement in their policy. Russ From Nicolas.Williams@sun.com Mon Apr 6 11:49:18 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D9F3A67A7; Mon, 6 Apr 2009 11:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.805 X-Spam-Level: X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 8wnAavvQYN-x; Mon, 6 Apr 2009 11:49:17 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 95DF828C2D7; Mon, 6 Apr 2009 11:49:17 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n36IoJZQ022450; Mon, 6 Apr 2009 18:50:19 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n36IoJXL050781; Mon, 6 Apr 2009 12:50:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n36IArHa004772; Mon, 6 Apr 2009 13:10:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n36IAra4004771; Mon, 6 Apr 2009 13:10:53 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 6 Apr 2009 13:10:53 -0500 From: Nicolas Williams To: Russ Housley Message-ID: <20090406181052.GF1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090406180424.BA7AC9A4749@odin.smetech.net> User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, nfsv4@ietf.org, Kurt Zeilenga , saag@ietf.org, nfs-discuss@opensolaris.org, Santosh Chokhani Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 18:49:18 -0000 On Mon, Apr 06, 2009 at 01:50:32PM -0400, Russ Housley wrote: > >On Mon, Apr 06, 2009 at 07:03:32AM -0400, Santosh Chokhani wrote: > >> I view SPIF as performing the following functions: converting machine to > >> human representation and vice versa; establishing equivalency between > >> two labeling policies, and defining which labels with the lattice are > >> valid and which are invalid. > > > >If I understand Russ' comment correctly the difficulty with SPIF lies in > >the label equivalency concept. I think there's a better solution for > >dealing with the idea that parts of a policy are classified differently > >than others. > > No. They are two separate concerns. > > Mapping labels between two different policies. Hopefully this can be > avoided altogether in the NFS context. There should be no impact from this on NFS. If a server is able to map some labels between multiple distinct DOIs, so much the better for it, but that would be an implementation detail. Making it possible to express label equivalencies is not an implementation detail. But it's also not a detail we should care about in the context of NFSv4, whereas security policy agreement _is_ something that we should care about in the context of NFSv4. > Some label values are not releasable to clients that do not have > access to data associated with that label. This one is a real-world > problem, and it leads to different clients having different subsets > of the SPIF if this community that is being supported has this > requirement in their policy. Right, that's what I meant, but I had misunderstood "label equivalency" as being related (d'oh). This is a problem that we must deal with to the extent that it impacts how a client and server determine that they agree on a common security policy. Nico -- From SChokhani@cygnacom.com Tue Apr 7 09:26:32 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EDF3A6832 for ; Tue, 7 Apr 2009 09:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 zVKj5CukvOGa for ; Tue, 7 Apr 2009 09:26:32 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 26E0D3A682D for ; Tue, 7 Apr 2009 09:26:30 -0700 (PDT) Received: (qmail 27478 invoked from network); 7 Apr 2009 16:19:37 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 7 Apr 2009 16:19:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 7 Apr 2009 12:20:48 -0400 Message-ID: In-Reply-To: <49DAC29D.6030902@schaufler-ca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Labeled-nfs] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm3LYXNazK6ZOCSSO6IHneU+cBaeQAbm6NA References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> From: "Santosh Chokhani" To: "Casey Schaufler" , "Russ Housley" Cc: Nicolas Williams , labeled-nfs@linux-nfs.org, nfsv4@ietf.org, Kurt Zeilenga , saag@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 16:26:32 -0000 One of looking at what Russ is saying is: 1. See if you can avoid security policy mapping, e.g., define a Common Extensible labeling Policy. 2. See if you can live without non-hierarchical security categories, since their very introduction brings in complexity. 3. See if you can live with only the hierarchical sensitivity levels mapping and without categories mapping. If the answer to 1 and 2 is no, the answer to this is likely to be no also. 4. See if you need to invalidate all the possible labels in the lattice. 5. Use the answers to 1 through 4 to tailor the SPIF. 6. See if you can achieve the same functionality using simpler paradigm. > -----Original Message----- > From: Casey Schaufler [mailto:casey@schaufler-ca.com]=20 > Sent: Monday, April 06, 2009 11:04 PM > To: Russ Housley > Cc: Nicolas Williams; Santosh Chokhani; saag@ietf.org;=20 > labeled-nfs@linux-nfs.org; Kurt Zeilenga;=20 > nfs-discuss@opensolaris.org; nfsv4@ietf.org; Casey Schaufler > Subject: Re: [Labeled-nfs] [saag] Common labeled security=20 > (comment on CALIPSO, labeled NFSv4) >=20 > Russ Housley wrote: > > ... > > > > No. They are two separate concerns. > > > > Mapping labels between two different policies. Hopefully=20 > this can be=20 > > avoided altogether in the NFS context. >=20 > I don't think so. Two SELinux machines will most likely have=20 > different policies even if they installed from the same media=20 > on similar hardware with similar configurations. If there's=20 > any reason for the NFS server to know anything about the=20 > client that impacts policy enforcement the server has to know=20 > enough to make that judgment correctly. If the server can=20 > ignore the client's policy there is no need to send any information. > If the server can't ignore the client's policy it needs to be=20 > able to reconcile the local policy to the remote policy in=20 > order to enforce reasonable policy. >=20 > The problem is that the server is using client subject=20 > information to enforce policy based on server object=20 > information. If the policies are similar (e.g. two Bell &=20 > LaPadula MLS systems) enforcement is merely difficult because=20 > the two system may have different values for what means=20 > "UNCLASSIFIED". For an SELinux system and an MLS system to=20 > work you've got much more on your hands than matching up=20 > category bits. If you don't do so however you can not make an=20 > access control decision based on the information passed from=20 > the other side that can possibly make sense. >=20 > You could decide that the server should enforce server policy=20 > and require that the client enforce client policy and hope=20 > that between the two nothing leaks out that you really care=20 > about. I seriously doubt that's what you want. >=20 > So you're back to mapping policies. You have to map policies=20 > if you want either side to do all the work. The mechanisms=20 > used to map labels used by different installations of the=20 > same 1990's MLS systems will not work for SELinux systems=20 > installed for different purposes by disjoint agencies. >=20 > I'm not trying to stop progress here. I am simply trying to=20 > point out that choosing a mechanism to implement a facility=20 > that won't work in the end is pretty pointless. Sure the old=20 > schemes worked in certain cases in the olden days. The=20 > question is will they work now, and the answer is obviously "no". >=20 >=20 >=20 From Nicolas.Williams@sun.com Tue Apr 7 10:22:51 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FC83A6929; Tue, 7 Apr 2009 10:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 St3tpdHQVnRT; Tue, 7 Apr 2009 10:22:50 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 17C913A67A6; Tue, 7 Apr 2009 10:22:50 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n37HNtdi009520; Tue, 7 Apr 2009 17:23:56 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n37HNtT0001428; Tue, 7 Apr 2009 11:23:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n37GiMiP005932; Tue, 7 Apr 2009 11:44:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n37GiLRw005931; Tue, 7 Apr 2009 11:44:21 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 7 Apr 2009 11:44:21 -0500 From: Nicolas Williams To: Casey Schaufler Message-ID: <20090407164420.GW1500@Sun.COM> References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49DAC29D.6030902@schaufler-ca.com> User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Santosh Chokhani Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 17:22:51 -0000 On Mon, Apr 06, 2009 at 08:03:57PM -0700, Casey Schaufler wrote: > I don't think so. Two SELinux machines will most likely have different > policies even if they installed from the same media on similar hardware > with similar configurations. If there's any reason for the NFS server > to know anything about the client that impacts policy enforcement the > server has to know enough to make that judgment correctly. If the server > can ignore the client's policy there is no need to send any information. > If the server can't ignore the client's policy it needs to be able to > reconcile the local policy to the remote policy in order to enforce > reasonable policy. We can have label-aware servers with non-label-aware protocols. But that's too constraining: it means clients have to be at a single label or otherwise communicate labels by convention (e.g., data location). It also means that interfaces to labeling will be proprietary. We can have non-label-aware server, non-label-aware protocols, and label aware clients, trusting the clients to enforce a common policy. But this too is too constraining: a) it forces one to associate labels with document _location_, b) it forces one to trust the clients too much. We need multi-level clients, since many users will have a range of clearances, not just a single one (and they need a trusted desktop). Given the above then we need label-aware servers and label-aware protocols so as to support for multi-level clients (with clients trusted to within a range of labels associated with clients' and users' authenticated identities and other authorization information). Even before putting labels on the wire we'd have a security policy management issue since storage can span many servers. With labels appearing on the wire (in IP headers, in application protocols, in PKIX certificate extensions and Kerberos V authorization- data, ...) we simply cannot avoid the need to express common security policies. We also cannot force everything and everyone to operate in a single DOI. And we cannot avoid the need to classify the security policies themselves, including varying classification for different subsets of the policies. IMO that means that we need something like SPIF, including: - a generic security policy data model/syntax - an interoperable encoding of security policies - a method by which two peers can detect and agree that they know a given common subset of a common security policy - label equivalencies The last item is the least critical -- we can deal with that later. > So you're back to mapping policies. You have to map policies if you > want either side to do all the work. The mechanisms used to map Yes. > labels used by different installations of the same 1990's MLS systems > will not work for SELinux systems installed for different purposes by > disjoint agencies. That's fine, unless you want them to interop and you can establish equivalencies. And provided SELinux can deal -- but that's less important because if it's just a small matter of programming (i.e., we have specs to code to or know what to code that we can write specs from) then it's just a matter of time. So we need to know whether solutions in this space are technically feasible. I believe they are. (We also need to know whether they are politically feasible, but here I think we'll find that they are politically required :) > I'm not trying to stop progress here. I am simply trying to point out > that choosing a mechanism to implement a facility that won't work in > the end is pretty pointless. Sure the old schemes worked in certain No one is knowingly proposing a mechanism that won't work so far as I can tell. > cases in the olden days. The question is will they work now, and the > answer is obviously "no". From casey@schaufler-ca.com Mon Apr 6 20:03:10 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF023A6B92 for ; Mon, 6 Apr 2009 20:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 wvACYOveHRK4 for ; Mon, 6 Apr 2009 20:03:03 -0700 (PDT) Received: from smtp101.prem.mail.sp1.yahoo.com (smtp101.prem.mail.sp1.yahoo.com [98.136.44.56]) by core3.amsl.com (Postfix) with SMTP id 987373A6D4E for ; Mon, 6 Apr 2009 20:03:02 -0700 (PDT) Received: (qmail 57973 invoked from network); 7 Apr 2009 03:04:08 -0000 Received: from unknown (HELO ?192.168.1.102?) (casey@64.41.22.89 with plain) by smtp101.prem.mail.sp1.yahoo.com with SMTP; 7 Apr 2009 03:04:08 -0000 X-YMail-OSG: ueV0.lYVM1nRbR5iB77VFh52zT7_k4d5WStHFc5QIs17tAowvYqD5oYKh20L0NmGMNBJP9PZKOFmGUw2xSeLOoRYZri.eiYUgg_hrW_sDT_UUSIu8m653yJpAtZovTPqllZ.QeTLI4uIQU.OTEJPnla43a6_PB5L6hwnVRFM2GjLRFkEdJVor1uFmU0IZOhDx2Hk942X61e5QPZr148m9OG0Y9uTcsl8GP72C_K8PE8Zcr7G9hmfKOgWfB4YjAyLjDqXj8hPPwkkrxlTCd3efQq0VuHYdDpwPlAEIdo56UdGCt7. X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DAC29D.6030902@schaufler-ca.com> Date: Mon, 06 Apr 2009 20:03:57 -0700 From: Casey Schaufler User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Russ Housley References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> In-Reply-To: <20090406180424.BA7AC9A4749@odin.smetech.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 07 Apr 2009 11:18:16 -0700 Cc: Nicolas Williams , labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Casey Schaufler , Santosh Chokhani Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 03:03:10 -0000 Russ Housley wrote: > ... > > No. They are two separate concerns. > > Mapping labels between two different policies. Hopefully this can be > avoided altogether in the NFS context. I don't think so. Two SELinux machines will most likely have different policies even if they installed from the same media on similar hardware with similar configurations. If there's any reason for the NFS server to know anything about the client that impacts policy enforcement the server has to know enough to make that judgment correctly. If the server can ignore the client's policy there is no need to send any information. If the server can't ignore the client's policy it needs to be able to reconcile the local policy to the remote policy in order to enforce reasonable policy. The problem is that the server is using client subject information to enforce policy based on server object information. If the policies are similar (e.g. two Bell & LaPadula MLS systems) enforcement is merely difficult because the two system may have different values for what means "UNCLASSIFIED". For an SELinux system and an MLS system to work you've got much more on your hands than matching up category bits. If you don't do so however you can not make an access control decision based on the information passed from the other side that can possibly make sense. You could decide that the server should enforce server policy and require that the client enforce client policy and hope that between the two nothing leaks out that you really care about. I seriously doubt that's what you want. So you're back to mapping policies. You have to map policies if you want either side to do all the work. The mechanisms used to map labels used by different installations of the same 1990's MLS systems will not work for SELinux systems installed for different purposes by disjoint agencies. I'm not trying to stop progress here. I am simply trying to point out that choosing a mechanism to implement a facility that won't work in the end is pretty pointless. Sure the old schemes worked in certain cases in the olden days. The question is will they work now, and the answer is obviously "no". From casey@schaufler-ca.com Tue Apr 7 20:02:08 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22DC13A6E39 for ; Tue, 7 Apr 2009 20:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 ULw9ZZogB1z4 for ; Tue, 7 Apr 2009 20:02:07 -0700 (PDT) Received: from smtp105.prem.mail.sp1.yahoo.com (smtp105.prem.mail.sp1.yahoo.com [98.136.44.60]) by core3.amsl.com (Postfix) with SMTP id 0B6703A6829 for ; Tue, 7 Apr 2009 20:01:59 -0700 (PDT) Received: (qmail 68806 invoked from network); 8 Apr 2009 03:03:06 -0000 Received: from unknown (HELO ?192.168.1.102?) (casey@64.41.22.89 with plain) by smtp105.prem.mail.sp1.yahoo.com with SMTP; 8 Apr 2009 03:03:05 -0000 X-YMail-OSG: ChUx_fQVM1kvWnap40cXzs0w.14_a4USXvW2sMfsxdDZkOfasABCYFCxBtLKieNOxl04tf531NpFlrD2XgyDx87DVudn7776xmRRT6vyFaKU223HN.gEXOjVHHEpvVIK1ty0YrxBKRrIfzKhqJthE8ruQPReSyeKljSfAImpH3c5oDaE52c7viN.a0phRtdBJSa7N6FhThG2DjMojEMdBH6JF5UQfv8GjHAMV0TE71sE7I0Sfz3kMtw.sWmj5yZlXm8R_.WLCkQclx5NMUWUjTBHZAz.esw17HrdNZHWZriSRILJ X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DC13DA.10405@schaufler-ca.com> Date: Tue, 07 Apr 2009 20:02:50 -0700 From: Casey Schaufler User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Williams References: <20090402154402.GM1500@Sun.COM> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> In-Reply-To: <20090407164420.GW1500@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Casey Schaufler , Santosh Chokhani Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 03:02:08 -0000 Nicolas Williams wrote: > On Mon, Apr 06, 2009 at 08:03:57PM -0700, Casey Schaufler wrote: > >> I don't think so. Two SELinux machines will most likely have different >> policies even if they installed from the same media on similar hardware >> with similar configurations. If there's any reason for the NFS server >> to know anything about the client that impacts policy enforcement the >> server has to know enough to make that judgment correctly. If the server >> can ignore the client's policy there is no need to send any information. >> If the server can't ignore the client's policy it needs to be able to >> reconcile the local policy to the remote policy in order to enforce >> reasonable policy. >> > > We can have label-aware servers with non-label-aware protocols. But > that's too constraining: it means clients have to be at a single label > or otherwise communicate labels by convention (e.g., data location). It > also means that interfaces to labeling will be proprietary. > > We can have non-label-aware server, non-label-aware protocols, and label > aware clients, trusting the clients to enforce a common policy. But > this too is too constraining: a) it forces one to associate labels with > document _location_, b) it forces one to trust the clients too much. > > We need multi-level clients, since many users will have a > range of clearances, not just a single one (and they need a trusted > desktop). > > Given the above then we need label-aware servers and label-aware > protocols so as to support for multi-level clients (with clients trusted > to within a range of labels associated with clients' and users' > authenticated identities and other authorization information). > > Even before putting labels on the wire we'd have a security policy > management issue since storage can span many servers. > > With labels appearing on the wire (in IP headers, in application > protocols, in PKIX certificate extensions and Kerberos V authorization- > data, ...) we simply cannot avoid the need to express common security > policies. We also cannot force everything and everyone to operate in a > single DOI. And we cannot avoid the need to classify the security > policies themselves, including varying classification for different > subsets of the policies. > > IMO that means that we need something like SPIF, including: > > - a generic security policy data model/syntax > - an interoperable encoding of security policies > - a method by which two peers can detect and agree that they know a > given common subset of a common security policy > - label equivalencies > > The last item is the least critical -- we can deal with that later. > Wow. Before I go too far, how familiar are you with MLS, SELinux, or Smack? All three provide general security policy models (Opinions vary on MLS) but none would lend themselves as a "generic" model. MLS is strictly oriented toward sensitivity, SELinux depends on the programs installed on the machine, and Smack uses no syntax in its labels at all. An interoperable encoding of policies might be possible for very limited policies. I suggest that mapping any other policy to the SELinux reference policy is beyond the state of the art, and I welcome an informed argument that proves me wrong. Two peers negotiating a policy subset? How does that help? Regarding the notion that the issue of label equivalences is "least critical", I don't see how you can claim to have successfully addressed any of the other bullet items without it. You're busy stocking the nursery and you haven't kissed the girl yet. If the information from the client is meaningless to the server the server can not use it to make an access control decision. Same goes the other way. With Smack I can assert that the label space for the client and server are the same and that it's OK if they use the labels passed around even if their rule sets differ. I know a good number of people who would find such an assertion dangerous, maybe even criminal. Label representations are meaningless without the policy behind them and mapping policies is hard enough that you could probably get a PHD from a reputable institution by measuring just how hard it is. >> So you're back to mapping policies. You have to map policies if you >> want either side to do all the work. The mechanisms used to map >> > > Yes. > > >> labels used by different installations of the same 1990's MLS systems >> will not work for SELinux systems installed for different purposes by >> disjoint agencies. >> > > That's fine, unless you want them to interop and you can establish > equivalencies. And provided SELinux can deal -- but that's less > important because if it's just a small matter of programming (i.e., we > have specs to code to or know what to code that we can write specs > from) then it's just a matter of time. > > So we need to know whether solutions in this space are technically > feasible. I believe they are. (We also need to know whether they are > politically feasible, but here I think we'll find that they are > politically required :) > > >> I'm not trying to stop progress here. I am simply trying to point out >> that choosing a mechanism to implement a facility that won't work in >> the end is pretty pointless. Sure the old schemes worked in certain >> > > No one is knowingly proposing a mechanism that won't work so far as I > can tell. > > >> cases in the olden days. The question is will they work now, and the >> answer is obviously "no". >> > > > From Nicolas.Williams@sun.com Tue Apr 7 22:56:13 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD573A6AD0; Tue, 7 Apr 2009 22:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 ZtFvP6YOU-Qn; Tue, 7 Apr 2009 22:56:12 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id E8F953A6A9B; Tue, 7 Apr 2009 22:56:11 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n385vI7n029537; Wed, 8 Apr 2009 05:57:19 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n385vIdf051880; Tue, 7 Apr 2009 23:57:18 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n385HmvC006318; Wed, 8 Apr 2009 00:17:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n385HjeS006317; Wed, 8 Apr 2009 00:17:45 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 8 Apr 2009 00:17:45 -0500 From: Nicolas Williams To: Casey Schaufler Message-ID: <20090408051745.GG1500@Sun.COM> References: <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49DC13DA.10405@schaufler-ca.com> User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Santosh Chokhani Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 05:56:13 -0000 On Tue, Apr 07, 2009 at 08:02:50PM -0700, Casey Schaufler wrote: > Wow. > > Before I go too far, how familiar are you with MLS, SELinux, or Smack? I'm familiar with Solaris TX (which is MLS). I'm also familiar with the OpenSolaris community that is trying to extend the TX model to include DTE. I don't know much at all about SELinux or Smack. I think common security policies for MLS are within reach. DTE... not so much. Some subsets of specific DTE policies, probably on a per-application basis, should be. > All three provide general security policy models (Opinions vary on MLS) > but none would lend themselves as a "generic" model. MLS is strictly > oriented toward sensitivity, SELinux depends on the programs installed > on the machine, and Smack uses no syntax in its labels at all. An > interoperable encoding of policies might be possible for very limited > policies. I suggest that mapping any other policy to the SELinux > reference policy is beyond the state of the art, and I welcome an > informed argument that proves me wrong. Two peers negotiating a IIUC it should be possible to generate SELinux policies from generic ones, but not the reverse. If so then that provides a path to interoperable deployment, though it would mean sacrificing some flexibility. Can you clarify my understanding? > policy subset? How does that help? Regarding the notion that the issue > of label equivalences is "least critical", I don't see how you can > claim to have successfully addressed any of the other bullet items > without it. Why send data at some label to a peer who doesn't understand what that label is? As for label equivalencies I was referring to the example cited earlier of multiple agencies with different MLS policies needing to communicate. To clarify: by "less critical" I meant that we could solve the equivalency problem later (provided we don't paint ourselves into any corners). > You're busy stocking the nursery and you haven't kissed the girl yet. Thanks. > If the information from the client is meaningless to the server the > server can not use it to make an access control decision. Same goes > the other way. With Smack I can assert that the label space for the Therein lies the interop problem. Will SELinux and Solaris TX interop with the labeled NFSv4 protocol we're working on? Evidently: not w/o policy agreement (that was Jarret's point, which kick-started this thread on the NFSv4 WG list). > client and server are the same and that it's OK if they use the labels > passed around even if their rule sets differ. I know a good number of > people who would find such an assertion dangerous, maybe even > criminal. Label representations are meaningless without the policy So you're saying that a) "a good number of people" think a solution is needed that allows the client and server to each know with certainty that the other will understand their labels, b) you're among those people (?), but c) no solution is feasible. Correct? So close up shop, forget interop? Or did I misunderstand you? What is the message that you're imparting here? I get the impression that it's "you can't solve this problem" and "I know what I'm doing" (and "you don't") but you're not telling us what it is that is. Is what you really mean "forget labeled protocol interop"? Please clarify. > behind them and mapping policies is hard enough that you could probably > get a PHD from a reputable institution by measuring just how hard it > is. I'm not interested in a PhD. I'm interested in solutions. SPIF is evidence that it's been tried. But I know little about how successful SPIF has been. Nico -- From jmorris@namei.org Wed Apr 8 03:44:20 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241C63A68A7; Wed, 8 Apr 2009 03:44:20 -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=[AWL=0.000, 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 DHGZyZwShJYy; Wed, 8 Apr 2009 03:44:19 -0700 (PDT) Received: from tundra.namei.org (tundra.namei.org [65.99.196.166]) by core3.amsl.com (Postfix) with ESMTP id 64B943A6A0E; Wed, 8 Apr 2009 03:44:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tundra.namei.org (8.13.1/8.13.1) with ESMTP id n38Aj7wU003842; Wed, 8 Apr 2009 06:45:07 -0400 Date: Wed, 8 Apr 2009 20:45:06 +1000 (EST) From: James Morris To: Nicolas Williams In-Reply-To: <20090408051745.GG1500@Sun.COM> Message-ID: References: <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> <20090408051745.GG1500@Sun.COM> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Casey Schaufler , Santosh Chokhani Subject: Re: [saag] [nfsv4] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 10:44:20 -0000 On Wed, 8 Apr 2009, Nicolas Williams wrote: > Therein lies the interop problem. Will SELinux and Solaris TX interop > with the labeled NFSv4 protocol we're working on? Evidently: not w/o > policy agreement (that was Jarret's point, which kick-started this > thread on the NFSv4 WG list). I don't know about TX, but it seems possible that someone might want to make SELinux with an MLS policy interoperate with a different MLS platform (note that this would not apply in the case of interop with purely legacy systems, as they won't have NFSv4.x support). I have no idea how likely this scenario is, and I wouldn't try to accommodate this goal in the protocol unless a stakeholder could make a solid case for it. Note that we should expect interoperability between Solaris FMAC and SELinux (i.e. the same security model implemented on different platforms, like Unix DAC). - James -- James Morris From SChokhani@cygnacom.com Wed Apr 8 04:18:39 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D793A696A for ; Wed, 8 Apr 2009 04:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 zwTI97DmPW09 for ; Wed, 8 Apr 2009 04:18:38 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 149913A68DA for ; Wed, 8 Apr 2009 04:18:37 -0700 (PDT) Received: (qmail 5687 invoked from network); 8 Apr 2009 11:18:31 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 8 Apr 2009 11:18:31 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 8 Apr 2009 07:19:44 -0400 Message-ID: In-Reply-To: <20090408051745.GG1500@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Labeled-nfs] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm4DdZywMe4VxsjTa+ox9nIjnTQcQALf5vg References: <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> <20090408051745.GG1500@Sun.COM> From: "Santosh Chokhani" To: "Nicolas Williams" , "Casey Schaufler" Cc: labeled-nfs@linux-nfs.org, nfsv4@ietf.org, Kurt Zeilenga , saag@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 11:18:39 -0000 SPIF has been successfully implemented and used.=20 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Wednesday, April 08, 2009 1:18 AM > To: Casey Schaufler > Cc: Russ Housley; Santosh Chokhani; saag@ietf.org;=20 > labeled-nfs@linux-nfs.org; Kurt Zeilenga;=20 > nfs-discuss@opensolaris.org; nfsv4@ietf.org > Subject: Re: [Labeled-nfs] [saag] Common labeled security=20 > (comment on CALIPSO, labeled NFSv4) >=20 > On Tue, Apr 07, 2009 at 08:02:50PM -0700, Casey Schaufler wrote: > > Wow. > >=20 > > Before I go too far, how familiar are you with MLS,=20 > SELinux, or Smack? >=20 > I'm familiar with Solaris TX (which is MLS). I'm also=20 > familiar with the OpenSolaris community that is trying to=20 > extend the TX model to include DTE. I don't know much at all=20 > about SELinux or Smack. >=20 > I think common security policies for MLS are within reach. =20 > DTE... not so much. Some subsets of specific DTE policies,=20 > probably on a per-application basis, should be. >=20 > > All three provide general security policy models (Opinions vary on=20 > > MLS) but none would lend themselves as a "generic" model. MLS is=20 > > strictly oriented toward sensitivity, SELinux depends on=20 > the programs=20 > > installed on the machine, and Smack uses no syntax in its labels at=20 > > all. An interoperable encoding of policies might be=20 > possible for very=20 > > limited policies. I suggest that mapping any other policy to the=20 > > SELinux reference policy is beyond the state of the art,=20 > and I welcome=20 > > an informed argument that proves me wrong. Two peers negotiating a >=20 > IIUC it should be possible to generate SELinux policies from=20 > generic ones, but not the reverse. If so then that provides=20 > a path to interoperable deployment, though it would mean=20 > sacrificing some flexibility. Can you clarify my understanding? >=20 > > policy subset? How does that help? Regarding the notion=20 > that the issue=20 > > of label equivalences is "least critical", I don't see how you can=20 > > claim to have successfully addressed any of the other bullet items=20 > > without it. >=20 > Why send data at some label to a peer who doesn't understand=20 > what that label is? >=20 > As for label equivalencies I was referring to the example=20 > cited earlier of multiple agencies with different MLS=20 > policies needing to communicate. > To clarify: by "less critical" I meant that we could solve=20 > the equivalency problem later (provided we don't paint=20 > ourselves into any corners). >=20 > > You're busy stocking the nursery and you haven't kissed the=20 > girl yet. >=20 > Thanks. >=20 > > If the information from the client is meaningless to the server the=20 > > server can not use it to make an access control decision. Same goes=20 > > the other way. With Smack I can assert that the label space for the >=20 > Therein lies the interop problem. Will SELinux and Solaris=20 > TX interop with the labeled NFSv4 protocol we're working on? =20 > Evidently: not w/o policy agreement (that was Jarret's point,=20 > which kick-started this thread on the NFSv4 WG list). >=20 > > client and server are the same and that it's OK if they use=20 > the labels=20 > > passed around even if their rule sets differ. I know a good=20 > number of=20 > > people who would find such an assertion dangerous, maybe even=20 > > criminal. Label representations are meaningless without the policy >=20 > So you're saying that a) "a good number of people" think a=20 > solution is needed that allows the client and server to each=20 > know with certainty that the other will understand their=20 > labels, b) you're among those people (?), but c) no solution=20 > is feasible. Correct? >=20 > So close up shop, forget interop? Or did I misunderstand=20 > you? What is the message that you're imparting here? I get=20 > the impression that it's "you can't solve this problem" and=20 > "I know what I'm doing" (and "you > don't") but you're not telling us what it is that is. Is=20 > what you really mean "forget labeled protocol interop"? =20 > Please clarify. >=20 > > behind them and mapping policies is hard enough that you could=20 > > probably get a PHD from a reputable institution by=20 > measuring just how=20 > > hard it is. >=20 > I'm not interested in a PhD. I'm interested in solutions. =20 > SPIF is evidence that it's been tried. But I know little=20 > about how successful SPIF has been. >=20 > Nico > --=20 >=20 From casey@schaufler-ca.com Wed Apr 8 09:10:10 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2E428C14F for ; Wed, 8 Apr 2009 09:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 dUEBZf1Bt8f6 for ; Wed, 8 Apr 2009 09:10:09 -0700 (PDT) Received: from smtp102.prem.mail.sp1.yahoo.com (smtp102.prem.mail.sp1.yahoo.com [98.136.44.57]) by core3.amsl.com (Postfix) with SMTP id BEAE43A6B36 for ; Wed, 8 Apr 2009 09:10:08 -0700 (PDT) Received: (qmail 99547 invoked from network); 8 Apr 2009 16:11:16 -0000 Received: from unknown (HELO ?192.168.1.102?) (casey@64.41.22.89 with plain) by smtp102.prem.mail.sp1.yahoo.com with SMTP; 8 Apr 2009 16:11:15 -0000 X-YMail-OSG: du3t1DgVM1nFd8tIOjxdhlDHr_BEy7WP0bpkf6F5zVTYnb8afa0Np8cgp3rDQrhNGwX6KYc0HkaoLxsoMnqz4.MxD3FnCpTozHvis4zc99UXry0dQj6n8nsAbvWQCWaD330nfSU4Ba3Y5uw5wqzDroPi5.MvzajYQILsLxGC1DFFIVaNoEE1oawoEQVN4.3gpcmBBeKfM0lr5kVGPkgSE8mYFUms6Kb3x0X9zhHZOOFQADd5yhbdjKiWj76M4FHaeKOUWz15xpsDEOt3fxS3ugYz_.ix8sKdqjuzLSTMbwiOBl9w X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DCCC94.80501@schaufler-ca.com> Date: Wed, 08 Apr 2009 09:11:00 -0700 From: Casey Schaufler User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Williams References: <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> <20090408051745.GG1500@Sun.COM> In-Reply-To: <20090408051745.GG1500@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Casey Schaufler , Santosh Chokhani Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:10:10 -0000 Nicolas Williams wrote: > On Tue, Apr 07, 2009 at 08:02:50PM -0700, Casey Schaufler wrote: > >> Wow. >> >> Before I go too far, how familiar are you with MLS, SELinux, or Smack? >> > > I'm familiar with Solaris TX (which is MLS). I'm also familiar with the > OpenSolaris community that is trying to extend the TX model to include > DTE. I don't know much at all about SELinux or Smack. > > I think common security policies for MLS are within reach. DTE... not > so much. Some subsets of specific DTE policies, probably on a > per-application basis, should be. > > The 1990's MLS solutions used labels that described sensitivity levels and category sets. There was variation on exactly how these were represented, some used fixed size bit maps, others arrays of category numbers, but the information they contain is a complete description of the information required to make an access control decision. Unfortunately to the task at hand, MLS is a technology that has seen its last development efforts. The SELinux label, whose textual representation is called a "context", contains enough information for the system on which it was generated to interpret it relative to the system policy. It does not contain sufficient information for a system that does understand that policy to make decisions based on that context. For a context generated on Stephen's machine to be meaningful on David's David's machine would need a full understanding of both policies. Last I looked the SELinux reference policy was approaching a million lines. Based on the many interrelationships between policy elements, I do not think that subsetting is going to be viable, although I'm willing to be educated on that. In some ways Smack is even worse. The Smack label contains no actual information, it is just a character string and the access control is left completely up to the access control rules specified on the system. A Smack label from Etienne's system has no intrinsic value on Casey's and give no hint as to how it should be interpreted or enforced. Summary: Old MLS systems passed sufficient information in their labels for any number of mechanisms including SPIF, CIPSO, TSIX, and IPSEC to be useful. 21st century MAC systems, including SELinux and Smack, have labels that do not contain sufficient information for another system to make an access control decision. >> All three provide general security policy models (Opinions vary on MLS) >> but none would lend themselves as a "generic" model. MLS is strictly >> oriented toward sensitivity, SELinux depends on the programs installed >> on the machine, and Smack uses no syntax in its labels at all. An >> interoperable encoding of policies might be possible for very limited >> policies. I suggest that mapping any other policy to the SELinux >> reference policy is beyond the state of the art, and I welcome an >> informed argument that proves me wrong. Two peers negotiating a >> > > IIUC it should be possible to generate SELinux policies from generic > ones, but not the reverse. If so then that provides a path to > interoperable deployment, though it would mean sacrificing some > flexibility. Can you clarify my understanding? > An SELinux policy can be created from scratch, and we're seeing some people in the embedded space trying to do just that. Sure, you can limit the problem by constraining the variation of the policies, but as we type the reference policy continues to be refined and expanded. I'm not going to tell Joshua that he has to slow policy development in support of NFS. >> policy subset? How does that help? Regarding the notion that the issue >> of label equivalences is "least critical", I don't see how you can >> claim to have successfully addressed any of the other bullet items >> without it. >> > > Why send data at some label to a peer who doesn't understand what that > label is? > > As for label equivalencies I was referring to the example cited earlier > of multiple agencies with different MLS policies needing to communicate. > To clarify: by "less critical" I meant that we could solve the > equivalency problem later (provided we don't paint ourselves into any > corners). > Let's see if I can be clear for a change. (smiley here) You are 100% correct. There is no point in sending a label to someone who can't understand it. You are also correct that in the case of MLS, where the label contains sufficient information to make an access control decision, perhaps after some amount of translation, label equivalence is a problem that shouldn't require all that much work. Industry experience from the 1990's backs you up. >> You're busy stocking the nursery and you haven't kissed the girl yet. >> > > Thanks. > > >> If the information from the client is meaningless to the server the >> server can not use it to make an access control decision. Same goes >> the other way. With Smack I can assert that the label space for the >> > > Therein lies the interop problem. Will SELinux and Solaris TX interop > with the labeled NFSv4 protocol we're working on? Evidently: not w/o > policy agreement (that was Jarret's point, which kick-started this > thread on the NFSv4 WG list). > Again, you are correct. Jarret is correct. The assumption that policy agreement can be assumed is inappropriate. >> client and server are the same and that it's OK if they use the labels >> passed around even if their rule sets differ. I know a good number of >> people who would find such an assertion dangerous, maybe even >> criminal. Label representations are meaningless without the policy >> > > So you're saying that a) "a good number of people" think a solution is > needed that allows the client and server to each know with certainty > that the other will understand their labels, b) you're among those > people (?), but c) no solution is feasible. Correct? > a) Else there's no point to labeled NFS. b) Yup. c) It is not feasible to meet "a" using just the information contained in either an SELinux context or a Smack label, regardless of how the information is transmitted between the client and server. You can meet "a" for 20th century MLS systems using just the information contained in the MLS label. > So close up shop, forget interop? Nope. > Or did I misunderstand you? I can see how you might come to your conclusions, sorry about being obtuse. > What is > the message that you're imparting here? The systems we created in an effort to appease "C2 in '92" were very different from the systems we're using now. The interoperability problem is not the same, and the mechanisms from the MLS era will not address the interoperability issues, although they could be a minor part of the end solution. > I get the impression that it's > "you can't solve this problem" Sure you can. My concern is that y'all are looking at the issue as a rehash of an MLS implementation, and it is much bigger than that. > and "I know what I'm doing" (and "you > don't") but you're not telling us what it is that is. Is what you > really mean "forget labeled protocol interop"? Please clarify. > No. I do have a bit of experience in the field, including close involvement with CIPSO, three different implementations of labeled NFS (SunOS/MLS, and two for Trusted Irix) and TSIG throughout its life, but in no way would I claim to be an expert on the right way to do protocols. I do understand Mandatory Access Control systems, and I do see that the discussion to date is missing an element that is key to the problem at hand. >> behind them and mapping policies is hard enough that you could probably >> get a PHD from a reputable institution by measuring just how hard it >> is. >> > > I'm not interested in a PhD. I'm interested in solutions. SPIF is > evidence that it's been tried. But I know little about how successful > SPIF has been. > I do not deny that SPIF (or CIPSO, or TSIX) has been successful for the problem it was designed to solve. This is not the same problem. I hope I've clarified the difference between the problem of MLS systems and the problem of our current set of technologies. Thank you. From Nicolas.Williams@sun.com Wed Apr 8 09:21:49 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3051A3A696F; Wed, 8 Apr 2009 09:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.81 X-Spam-Level: X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 CHWMs9ZfrM3h; Wed, 8 Apr 2009 09:21:48 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 749173A68FE; Wed, 8 Apr 2009 09:21:48 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n38GMtUK000453; Wed, 8 Apr 2009 16:22:56 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n38GMt5I064008; Wed, 8 Apr 2009 10:22:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n38FhV23006523; Wed, 8 Apr 2009 10:43:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n38FhTaV006522; Wed, 8 Apr 2009 10:43:29 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 8 Apr 2009 10:43:29 -0500 From: Nicolas Williams To: James Morris Message-ID: <20090408154329.GJ1500@Sun.COM> References: <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> <20090408051745.GG1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Casey Schaufler , Santosh Chokhani Subject: Re: [saag] [nfsv4] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:21:49 -0000 On Wed, Apr 08, 2009 at 08:45:06PM +1000, James Morris wrote: > I don't know about TX, but it seems possible that someone might want to > make SELinux with an MLS policy interoperate with a different MLS platform > (note that this would not apply in the case of interop with purely legacy > systems, as they won't have NFSv4.x support). I have no idea how likely > this scenario is, and I wouldn't try to accommodate this goal in the > protocol unless a stakeholder could make a solid case for it. Well, here at the IETF we do like to have interoperable protocols. We ought to at least try. > Note that we should expect interoperability between Solaris FMAC and > SELinux (i.e. the same security model implemented on different platforms, > like Unix DAC). OK. From SChokhani@cygnacom.com Wed Apr 8 09:43:03 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0EAF3A6E64 for ; Wed, 8 Apr 2009 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 L5zQh7e3HNmo for ; Wed, 8 Apr 2009 09:43:03 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 1AC423A6B56 for ; Wed, 8 Apr 2009 09:43:03 -0700 (PDT) Received: (qmail 8383 invoked from network); 8 Apr 2009 16:36:15 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 8 Apr 2009 16:36:15 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 8 Apr 2009 12:37:27 -0400 Message-ID: In-Reply-To: <49DCCC94.80501@schaufler-ca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Labeled-nfs] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4) Thread-Index: Acm4ZKYav9K5r6D+SZig6iq5E/clHQAA3PuQ References: <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> <20090408051745.GG1500@Sun.COM> <49DCCC94.80501@schaufler-ca.com> From: "Santosh Chokhani" To: "Casey Schaufler" , "Nicolas Williams" Cc: labeled-nfs@linux-nfs.org, nfsv4@ietf.org, Kurt Zeilenga , saag@ietf.org, nfs-discuss@opensolaris.org Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:43:03 -0000 If the label from a system does not carry the policy associated with the label, could the policy not be construed from the authenticated system identity. Not an ideal solution and will have issues, but is doable. > -----Original Message----- > From: Casey Schaufler [mailto:casey@schaufler-ca.com]=20 > Sent: Wednesday, April 08, 2009 12:11 PM > To: Nicolas Williams > Cc: Russ Housley; Santosh Chokhani; saag@ietf.org;=20 > labeled-nfs@linux-nfs.org; Kurt Zeilenga;=20 > nfs-discuss@opensolaris.org; nfsv4@ietf.org; Casey Schaufler > Subject: Re: [Labeled-nfs] [saag] Common labeled security=20 > (comment on CALIPSO, labeled NFSv4) >=20 > Nicolas Williams wrote: > > On Tue, Apr 07, 2009 at 08:02:50PM -0700, Casey Schaufler wrote: > > =20 > >> Wow. > >> > >> Before I go too far, how familiar are you with MLS,=20 > SELinux, or Smack? > >> =20 > > > > I'm familiar with Solaris TX (which is MLS). I'm also=20 > familiar with=20 > > the OpenSolaris community that is trying to extend the TX model to=20 > > include DTE. I don't know much at all about SELinux or Smack. > > > > I think common security policies for MLS are within reach. =20 > DTE... not=20 > > so much. Some subsets of specific DTE policies, probably on a=20 > > per-application basis, should be. > > > > =20 >=20 > The 1990's MLS solutions used labels that described=20 > sensitivity levels and category sets. There was variation on=20 > exactly how these were represented, some used fixed size bit=20 > maps, others arrays of category numbers, but the information=20 > they contain is a complete description of the information=20 > required to make an access control decision. Unfortunately to=20 > the task at hand, MLS is a technology that has seen its last=20 > development efforts. >=20 > The SELinux label, whose textual representation is called a=20 > "context", contains enough information for the system on=20 > which it was generated to interpret it relative to the system=20 > policy. It does not contain sufficient information for a=20 > system that does understand that policy to make decisions=20 > based on that context. For a context generated on Stephen's=20 > machine to be meaningful on David's David's machine would=20 > need a full understanding of both policies. Last I looked the=20 > SELinux reference policy was approaching a million lines.=20 > Based on the many interrelationships between policy elements,=20 > I do not think that subsetting is going to be viable,=20 > although I'm willing to be educated on that. >=20 > In some ways Smack is even worse. The Smack label contains no=20 > actual information, it is just a character string and the=20 > access control is left completely up to the access control=20 > rules specified on the system. A Smack label from Etienne's=20 > system has no intrinsic value on Casey's and give no hint as=20 > to how it should be interpreted or enforced. >=20 > Summary: Old MLS systems passed sufficient information in=20 > their labels for any number of mechanisms including SPIF,=20 > CIPSO, TSIX, and IPSEC to be useful. 21st century MAC=20 > systems, including SELinux and Smack, have labels that do not=20 > contain sufficient information for another system to make an=20 > access control decision. >=20 > >> All three provide general security policy models (Opinions vary on=20 > >> MLS) but none would lend themselves as a "generic" model. MLS is=20 > >> strictly oriented toward sensitivity, SELinux depends on=20 > the programs=20 > >> installed on the machine, and Smack uses no syntax in its=20 > labels at=20 > >> all. An interoperable encoding of policies might be=20 > possible for very=20 > >> limited policies. I suggest that mapping any other policy to the=20 > >> SELinux reference policy is beyond the state of the art, and I=20 > >> welcome an informed argument that proves me wrong. Two peers=20 > >> negotiating a > >> =20 > > > > IIUC it should be possible to generate SELinux policies=20 > from generic=20 > > ones, but not the reverse. If so then that provides a path to=20 > > interoperable deployment, though it would mean sacrificing some=20 > > flexibility. Can you clarify my understanding? > > =20 >=20 > An SELinux policy can be created from scratch, and we're=20 > seeing some people in the embedded space trying to do just=20 > that. Sure, you can limit the problem by constraining the=20 > variation of the policies, but as we type the reference=20 > policy continues to be refined and expanded. > I'm not going to tell Joshua that he has to slow policy=20 > development in support of NFS. >=20 > >> policy subset? How does that help? Regarding the notion that the=20 > >> issue of label equivalences is "least critical", I don't=20 > see how you=20 > >> can claim to have successfully addressed any of the other bullet=20 > >> items without it. > >> =20 > > > > Why send data at some label to a peer who doesn't=20 > understand what that=20 > > label is? > > > > As for label equivalencies I was referring to the example cited=20 > > earlier of multiple agencies with different MLS policies=20 > needing to communicate. > > To clarify: by "less critical" I meant that we could solve the=20 > > equivalency problem later (provided we don't paint=20 > ourselves into any=20 > > corners). > > =20 >=20 > Let's see if I can be clear for a change. (smiley here) >=20 > You are 100% correct. There is no point in sending a label to=20 > someone who can't understand it. >=20 > You are also correct that in the case of MLS, where the label=20 > contains sufficient information to make an access control=20 > decision, perhaps after some amount of translation, label=20 > equivalence is a problem that shouldn't require all that much=20 > work. Industry experience from the 1990's backs you up. >=20 > >> You're busy stocking the nursery and you haven't kissed=20 > the girl yet. > >> =20 > > > > Thanks. > > > > =20 > >> If the information from the client is meaningless to the=20 > server the=20 > >> server can not use it to make an access control decision.=20 > Same goes=20 > >> the other way. With Smack I can assert that the label space for the > >> =20 > > > > Therein lies the interop problem. Will SELinux and Solaris=20 > TX interop=20 > > with the labeled NFSv4 protocol we're working on? =20 > Evidently: not w/o=20 > > policy agreement (that was Jarret's point, which kick-started this=20 > > thread on the NFSv4 WG list). > > =20 >=20 > Again, you are correct. Jarret is correct. >=20 > The assumption that policy agreement can be assumed is inappropriate. >=20 > >> client and server are the same and that it's OK if they use the=20 > >> labels passed around even if their rule sets differ. I know a good=20 > >> number of people who would find such an assertion dangerous, maybe=20 > >> even criminal. Label representations are meaningless without the=20 > >> policy > >> =20 > > > > So you're saying that a) "a good number of people" think a=20 > solution is=20 > > needed that allows the client and server to each know with=20 > certainty=20 > > that the other will understand their labels, b) you're among those=20 > > people (?), but c) no solution is feasible. Correct? > > =20 >=20 > a) Else there's no point to labeled NFS. > b) Yup. > c) It is not feasible to meet "a" using just the information contained > in either an SELinux context or a Smack label, regardless of how > the information is transmitted between the client and server. You > can meet "a" for 20th century MLS systems using just the=20 > information > contained in the MLS label. >=20 > > So close up shop, forget interop? >=20 > Nope. >=20 > > Or did I misunderstand you? =20 >=20 > I can see how you might come to your conclusions, sorry about=20 > being obtuse. >=20 > > What is > > the message that you're imparting here? =20 >=20 > The systems we created in an effort to appease "C2 in '92"=20 > were very different from the systems we're using now. The=20 > interoperability problem is not the same, and the mechanisms=20 > from the MLS era will not address the interoperability=20 > issues, although they could be a minor part of the end solution. >=20 > > I get the impression that it's > > "you can't solve this problem" >=20 > Sure you can. My concern is that y'all are looking at the=20 > issue as a rehash of an MLS implementation, and it is much=20 > bigger than that. >=20 > > and "I know what I'm doing" (and "you > > don't") but you're not telling us what it is that is. Is what you=20 > > really mean "forget labeled protocol interop"? Please clarify. > > =20 >=20 > No. I do have a bit of experience in the field, including=20 > close involvement with CIPSO, three different implementations=20 > of labeled NFS (SunOS/MLS, and two for Trusted Irix) and TSIG=20 > throughout its life, but in no way would I claim to be an=20 > expert on the right way to do protocols. I do understand=20 > Mandatory Access Control systems, and I do see that the=20 > discussion to date is missing an element that is key to the=20 > problem at hand. >=20 > >> behind them and mapping policies is hard enough that you could=20 > >> probably get a PHD from a reputable institution by=20 > measuring just how=20 > >> hard it is. > >> =20 > > > > I'm not interested in a PhD. I'm interested in solutions. SPIF is=20 > > evidence that it's been tried. But I know little about how=20 > successful=20 > > SPIF has been. > > =20 >=20 > I do not deny that SPIF (or CIPSO, or TSIX) has been=20 > successful for the problem it was designed to solve. This is=20 > not the same problem. > I hope I've clarified the difference between the problem of=20 > MLS systems and the problem of our current set of technologies. >=20 >=20 > Thank you. >=20 >=20 From Nicolas.Williams@sun.com Wed Apr 8 14:50:29 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8740C3A6988; Wed, 8 Apr 2009 14:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 g5ebErg3SsXe; Wed, 8 Apr 2009 14:50:28 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 0B8743A6E82; Wed, 8 Apr 2009 14:50:27 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n38LpZxc010247; Wed, 8 Apr 2009 21:51:35 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n38LpYlH028697; Wed, 8 Apr 2009 15:51:34 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n38LCARu006680; Wed, 8 Apr 2009 16:12:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n38LC9HT006679; Wed, 8 Apr 2009 16:12:09 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 8 Apr 2009 16:12:09 -0500 From: Nicolas Williams To: Casey Schaufler Message-ID: <20090408211209.GS1500@Sun.COM> References: <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> <20090408051745.GG1500@Sun.COM> <49DCCC94.80501@schaufler-ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49DCCC94.80501@schaufler-ca.com> User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Santosh Chokhani Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 21:50:29 -0000 On Wed, Apr 08, 2009 at 09:11:00AM -0700, Casey Schaufler wrote: > The 1990's MLS solutions used labels that described sensitivity > levels and category sets. There was variation on exactly how > these were represented, some used fixed size bit maps, others > arrays of category numbers, but the information they contain is > a complete description of the information required to make an > access control decision. Unfortunately to the task at hand, MLS > is a technology that has seen its last development efforts. But has MLS seen its last days for deployment? I think that for generic non-governmental agency deployment you're quite right that MLS is barely sufficient. DTE is needed. Incidentally, I should clarify that in the context of labeled NFS I only care to solve the sub-problem of how the client and server can determine what policy or subset thereof they share. I currently think that's a simpler problem than how to represent policies (and equivalencies), but only if we also assume a solution that. > The SELinux label, whose textual representation is called a "context", > contains enough information for the system on which it was generated > to interpret it relative to the system policy. It does not contain > sufficient information for a system that does understand that policy > to make decisions based on that context. For a context generated on > Stephen's machine to be meaningful on David's David's machine would > need a full understanding of both policies. Last I looked the > SELinux reference policy was approaching a million lines. Based on > the many interrelationships between policy elements, I do not > think that subsetting is going to be viable, although I'm willing > to be educated on that. I'm still learning about DTE. If I understand correctly though we could constrain ourselves to administrator defined policies built on system- and vendor-defined types/roles. If so then DTE policy subset agreement seems within reach. > In some ways Smack is even worse. The Smack label contains no > actual information, it is just a character string and the access > control is left completely up to the access control rules specified > on the system. A Smack label from Etienne's system has no intrinsic > value on Casey's and give no hint as to how it should be interpreted > or enforced. Ouch. > Summary: Old MLS systems passed sufficient information in their > labels for any number of mechanisms including SPIF, CIPSO, TSIX, > and IPSEC to be useful. 21st century MAC systems, including > SELinux and Smack, have labels that do not contain sufficient > information for another system to make an access control decision. Jarret's point was that this is true even for MLS labels because a node might not know what the meaning of a given sensitivity and compartment are. This is not a problem for CALIPSO because middle boxes need only determine label dominance, but Jarret thinks that this is a problem for NFS. > > IIUC it should be possible to generate SELinux policies from generic > > ones, but not the reverse. If so then that provides a path to > > interoperable deployment, though it would mean sacrificing some > > flexibility. Can you clarify my understanding? > > An SELinux policy can be created from scratch, and we're seeing some > people in the embedded space trying to do just that. Sure, you can > limit the problem by constraining the variation of the policies, but > as we type the reference policy continues to be refined and expanded. > I'm not going to tell Joshua that he has to slow policy development > in support of NFS. I see. This is important knowledge. I'm not sure what can be done about that. > Let's see if I can be clear for a change. (smiley here) :) > The assumption that policy agreement can be assumed is inappropriate. I think you're very likely right about that w.r.t. DTE. But I still harbor some hope. > > So you're saying that a) "a good number of people" think a solution is > > needed that allows the client and server to each know with certainty > > that the other will understand their labels, b) you're among those > > people (?), but c) no solution is feasible. Correct? > > > > a) Else there's no point to labeled NFS. > b) Yup. > c) It is not feasible to meet "a" using just the information contained > in either an SELinux context or a Smack label, regardless of how > the information is transmitted between the client and server. You > can meet "a" for 20th century MLS systems using just the information > contained in the MLS label. Crystal clear. Thanks. > I hope I've clarified the difference between the problem of MLS systems > and the problem of our current set of technologies. You have. Thanks! I'll need to think about the DTE issues, and SELinux vs. Solaris FMAC. Nico -- From Jarrett.Lu@Sun.COM Wed Apr 8 15:42:15 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0283A6E74; Wed, 8 Apr 2009 15:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 uJ7N3jYCZFtI; Wed, 8 Apr 2009 15:42:14 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id 5FC603A6E75; Wed, 8 Apr 2009 15:41:09 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n38MgA9i015826; Wed, 8 Apr 2009 15:42:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHT00G0008IBS00@fe-sfbay-09.sun.com>; Wed, 08 Apr 2009 15:42:10 -0700 (PDT) Received: from [192.168.1.124] ([unknown] [98.234.224.236]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHT005FC0DWJ9C0@fe-sfbay-09.sun.com>; Wed, 08 Apr 2009 15:41:56 -0700 (PDT) Date: Wed, 08 Apr 2009 15:41:55 -0700 From: Jarrett Lu In-reply-to: <20090408211209.GS1500@Sun.COM> Sender: Jarrett.Lu@Sun.COM To: Nicolas Williams Message-id: <49DD2833.9060301@sun.com> References: <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> <20090408051745.GG1500@Sun.COM> <49DCCC94.80501@schaufler-ca.com> <20090408211209.GS1500@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Casey Schaufler , Santosh Chokhani Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jarrett.Lu@Sun.COM List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 22:42:15 -0000 Nicolas Williams wrote: > On Wed, Apr 08, 2009 at 09:11:00AM -0700, Casey Schaufler wrote: > >> The 1990's MLS solutions used labels that described sensitivity >> levels and category sets. There was variation on exactly how >> these were represented, some used fixed size bit maps, others >> arrays of category numbers, but the information they contain is >> a complete description of the information required to make an >> access control decision. Unfortunately to the task at hand, MLS >> is a technology that has seen its last development efforts. >> > > But has MLS seen its last days for deployment? I think that for generic > non-governmental agency deployment you're quite right that MLS is barely > sufficient. DTE is needed. > > Incidentally, I should clarify that in the context of labeled NFS I only > care to solve the sub-problem of how the client and server can determine > what policy or subset thereof they share. I currently think that's a > simpler problem than how to represent policies (and equivalencies), but > only if we also assume a solution that. > > >> The SELinux label, whose textual representation is called a "context", >> contains enough information for the system on which it was generated >> to interpret it relative to the system policy. It does not contain >> sufficient information for a system that does understand that policy >> to make decisions based on that context. For a context generated on >> Stephen's machine to be meaningful on David's David's machine would >> need a full understanding of both policies. Last I looked the >> SELinux reference policy was approaching a million lines. Based on >> the many interrelationships between policy elements, I do not >> think that subsetting is going to be viable, although I'm willing >> to be educated on that. >> > > I'm still learning about DTE. If I understand correctly though we could > constrain ourselves to administrator defined policies built on system- > and vendor-defined types/roles. If so then DTE policy subset agreement > seems within reach. > It's not clear to me how much information is sufficient to guarantee a subset of policy is consistent so that labeled communication is safe and correct. One extreme is to require systems to be configured identically. As I understand it, roles/types on DTE systems usually depend on what kind of applications are run on the systems, and the types are defined to constrains what the applications can do on a system. In other words, policy on different systems are most likely different. >> In some ways Smack is even worse. The Smack label contains no >> actual information, it is just a character string and the access >> control is left completely up to the access control rules specified >> on the system. A Smack label from Etienne's system has no intrinsic >> value on Casey's and give no hint as to how it should be interpreted >> or enforced. >> > > Ouch. > > >> Summary: Old MLS systems passed sufficient information in their >> labels for any number of mechanisms including SPIF, CIPSO, TSIX, >> and IPSEC to be useful. 21st century MAC systems, including >> SELinux and Smack, have labels that do not contain sufficient >> information for another system to make an access control decision. >> > > Jarret's point was that this is true even for MLS labels because a node > might not know what the meaning of a given sensitivity and compartment > are. This is not a problem for CALIPSO because middle boxes need only > determine label dominance, but Jarret thinks that this is a problem for > NFS. > I believe this is a problem for MLS end systems (client and server), even when CALIPSO is in use. If labels are defined differently on different systems, e.g. same binary bit patten on two different systems maps to different labels, label comparison is meaningless. The underlying assumption is that if two systems use different label mapping schemes, they should not be using the same DOI to communicate without some sort of translation mechanism. The agreement of associating a DOI with a particular label mapping is done outside of a protocol option such as CIPSO (for IPv4) or CALIPSO (for IPv6). Just to be clear, CALIPSO spec defines "on-the-wire" format of (MLS) sensitivity label option for IPv6. It is not designed to communicate policy agreements among systems. Jarrett From jmorris@namei.org Wed Apr 8 16:25:31 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773FB3A6BA3; Wed, 8 Apr 2009 16:25:31 -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 ALqEb+FVGsVW; Wed, 8 Apr 2009 16:25:27 -0700 (PDT) Received: from tundra.namei.org (tundra.namei.org [65.99.196.166]) by core3.amsl.com (Postfix) with ESMTP id 836653A6BAB; Wed, 8 Apr 2009 16:25:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tundra.namei.org (8.13.1/8.13.1) with ESMTP id n38NQScg008811; Wed, 8 Apr 2009 19:26:29 -0400 Date: Thu, 9 Apr 2009 09:26:28 +1000 (EST) From: James Morris To: Nicolas Williams In-Reply-To: <20090408211209.GS1500@Sun.COM> Message-ID: References: <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> <20090408051745.GG1500@Sun.COM> <49DCCC94.80501@schaufler-ca.com> <20090408211209.GS1500@Sun.COM> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Casey Schaufler , Santosh Chokhani Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:25:31 -0000 On Wed, 8 Apr 2009, Nicolas Williams wrote: > > In some ways Smack is even worse. The Smack label contains no > > actual information, it is just a character string and the access > > control is left completely up to the access control rules specified > > on the system. A Smack label from Etienne's system has no intrinsic > > value on Casey's and give no hint as to how it should be interpreted > > or enforced. > > Ouch. It's not a new problem. On a standard DAC Unix system, what does 'admin' mean as the owner of a file? The reason why labeling protocols were so simple for MLS was that the security policy was fixed. This is also why MLS is useless for most people and why we now have TE. - James -- James Morris From Nicolas.Williams@sun.com Wed Apr 8 16:26:10 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4FF3A6BA1; Wed, 8 Apr 2009 16:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 ApIz5S31+p9v; Wed, 8 Apr 2009 16:26:09 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 27AD03A6B6A; Wed, 8 Apr 2009 16:26:09 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n38NRGWB014227; Wed, 8 Apr 2009 23:27:16 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n38NRFgx062604; Wed, 8 Apr 2009 17:27:15 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n38Mlt8c006842; Wed, 8 Apr 2009 17:47:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n38Mlthh006841; Wed, 8 Apr 2009 17:47:55 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 8 Apr 2009 17:47:55 -0500 From: Nicolas Williams To: Jarrett Lu Message-ID: <20090408224755.GV1500@Sun.COM> References: <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> <20090408051745.GG1500@Sun.COM> <49DCCC94.80501@schaufler-ca.com> <20090408211209.GS1500@Sun.COM> <49DD2833.9060301@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49DD2833.9060301@sun.com> User-Agent: Mutt/1.5.7i Cc: labeled-nfs@linux-nfs.org, Kurt Zeilenga , nfsv4@ietf.org, saag@ietf.org, nfs-discuss@opensolaris.org, Casey Schaufler , Santosh Chokhani Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:26:10 -0000 On Wed, Apr 08, 2009 at 03:41:55PM -0700, Jarrett Lu wrote: > It's not clear to me how much information is sufficient to guarantee a > subset of policy is consistent so that labeled communication is safe and > correct. One extreme is to require systems to be configured identically. > As I understand it, roles/types on DTE systems usually depend on what > kind of applications are run on the systems, and the types are defined > to constrains what the applications can do on a system. In other words, > policy on different systems are most likely different. Right, but presumably applications using NFS can be made to have identical sub-policies on all relevant NFS clients and servers. If not then why use NFS for such an application? Of course, there's the matter of home directories and random apps loaded on clients without server knowledge, but if you're using labeled NFS then presumably you have an infrastructure and site-/org-wide system administration that can ensure orderly application deployment. > >Jarret's point was that this is true even for MLS labels because a node > >might not know what the meaning of a given sensitivity and compartment > >are. This is not a problem for CALIPSO because middle boxes need only > >determine label dominance, but Jarret thinks that this is a problem for > >NFS. > > > > I believe this is a problem for MLS end systems (client and server), > even when CALIPSO is in use. If labels are defined differently on > different systems, e.g. same binary bit patten on two different systems > maps to different labels, label comparison is meaningless. The > underlying assumption is that if two systems use different label mapping > schemes, they should not be using the same DOI to communicate without > some sort of translation mechanism. The agreement of associating a DOI > with a particular label mapping is done outside of a protocol option > such as CIPSO (for IPv4) or CALIPSO (for IPv6). Just to be clear, > CALIPSO spec defines "on-the-wire" format of (MLS) sensitivity label > option for IPv6. It is not designed to communicate policy agreements > among systems. Based on this I think I'm ready to conclude that for MLS we don't need anything more than the DOI number/name to produce MLS policy agreement, though a URI scheme for naming policies (including version) would have better semantics. DTE does not seem as simple, though assuming common per-app sub-policies then it may be doable. Nico -- From casey@schaufler-ca.com Wed Apr 8 18:03:49 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE79D3A6824 for ; Wed, 8 Apr 2009 18:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 N1Xww6Lx2Gxz for ; Wed, 8 Apr 2009 18:03:48 -0700 (PDT) Received: from smtp110.prem.mail.sp1.yahoo.com (smtp110.prem.mail.sp1.yahoo.com [98.136.44.55]) by core3.amsl.com (Postfix) with SMTP id B73693A6857 for ; Wed, 8 Apr 2009 18:03:48 -0700 (PDT) Received: (qmail 11711 invoked from network); 9 Apr 2009 01:04:56 -0000 Received: from unknown (HELO ?192.168.1.102?) (casey@64.41.22.89 with plain) by smtp110.prem.mail.sp1.yahoo.com with SMTP; 9 Apr 2009 01:04:55 -0000 X-YMail-OSG: EEgNXS0VM1nJjK3ra4t4dhTo0eZ43uSUegyBh1QKlRr7z9e8pBIP21ruaSBkZV1qDZA6ornLb.RNcoKJhp.Ppq9hedanBOSIDkI.yXaZeyG8x6CxZyg.vi5noboPUVKCK5hPKLpdNlXUDd1Pk9Cp6oTl257V1GyxFkaRvaM9xnhxyago2hoQtqhP.PzjMAtKW96ZopiFjhEcFWAfWfq0Vrsq6CDEySYWiWpefQvCR3_a.DkuDaBfj6Pf7y8ExKUX41BRf2L9l9Ti.pr4JZTUQjzMIAmXFXH5ozH6lGxe0wwnzIV9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DD49A8.4080903@schaufler-ca.com> Date: Wed, 08 Apr 2009 18:04:40 -0700 From: Casey Schaufler User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Williams References: <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net> <49DAC29D.6030902@schaufler-ca.com> <20090407164420.GW1500@Sun.COM> <49DC13DA.10405@schaufler-ca.com> <20090408051745.GG1500@Sun.COM> <49DCCC94.80501@schaufler-ca.com> <20090408211209.GS1500@Sun.COM> <49DD2833.9060301@sun.com> <20090408224755.GV1500@Sun.COM> In-Reply-To: <20090408224755.GV1500@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: labeled-nfs@linux-nfs.org, nfsv4@ietf.org, Kurt Zeilenga , saag@ietf.org, nfs-discuss@opensolaris.org, Casey Schaufler , Jarrett Lu , Santosh Chokhani Subject: Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 01:03:49 -0000 Nicolas Williams wrote: > On Wed, Apr 08, 2009 at 03:41:55PM -0700, Jarrett Lu wrote: > >> It's not clear to me how much information is sufficient to guarantee a >> subset of policy is consistent so that labeled communication is safe and >> correct. One extreme is to require systems to be configured identically. >> As I understand it, roles/types on DTE systems usually depend on what >> kind of applications are run on the systems, and the types are defined >> to constrains what the applications can do on a system. In other words, >> policy on different systems are most likely different. >> > > Right, but presumably applications using NFS can be made to have > identical sub-policies on all relevant NFS clients and servers. I do not believe that you can make that assumption with SELinux. > If not > then why use NFS for such an application? That is a very good question. > Of course, there's the matter > of home directories and random apps loaded on clients without server > knowledge, but if you're using labeled NFS then presumably you have an > infrastructure and site-/org-wide system administration that can ensure > orderly application deployment. > > That's quite an assumption. >>> Jarret's point was that this is true even for MLS labels because a node >>> might not know what the meaning of a given sensitivity and compartment >>> are. This is not a problem for CALIPSO because middle boxes need only >>> determine label dominance, but Jarret thinks that this is a problem for >>> NFS. >>> >>> >> I believe this is a problem for MLS end systems (client and server), >> even when CALIPSO is in use. If labels are defined differently on >> different systems, e.g. same binary bit patten on two different systems >> maps to different labels, label comparison is meaningless. The >> underlying assumption is that if two systems use different label mapping >> schemes, they should not be using the same DOI to communicate without >> some sort of translation mechanism. The agreement of associating a DOI >> with a particular label mapping is done outside of a protocol option >> such as CIPSO (for IPv4) or CALIPSO (for IPv6). Just to be clear, >> CALIPSO spec defines "on-the-wire" format of (MLS) sensitivity label >> option for IPv6. It is not designed to communicate policy agreements >> among systems. >> > > Based on this I think I'm ready to conclude that for MLS we don't need > anything more than the DOI number/name to produce MLS policy agreement, > though a URI scheme for naming policies (including version) would have > better semantics. MLS is an easier problem to solve, unfortunately it is a technology that has fallen off the roadmap. > DTE does not seem as simple, though assuming common > per-app sub-policies then it may be doable. > If you can create an uber-policy that can be shown to incorporate all the aspects of both the client policy and the server policy, one case of which being either the client policy or the server policy being a sub-set of the other, you may have a chance. Each policy is a million lines. From Pasi.Eronen@nokia.com Tue Apr 14 23:11:16 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C303A6B5F for ; Tue, 14 Apr 2009 23:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 tTj8GCVKy3bD for ; Tue, 14 Apr 2009 23:11:15 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CE3933A697F for ; Tue, 14 Apr 2009 23:11:14 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3F6CL5w003638; Wed, 15 Apr 2009 01:12:27 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 09:12:16 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 09:12:16 +0300 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 15 Apr 2009 08:12:15 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Wed, 15 Apr 2009 08:12:04 +0200 From: To: Date: Wed, 15 Apr 2009 08:12:03 +0200 Thread-Topic: Soliciting reviews for Cross-Origin Resource Sharing Thread-Index: Acm2nbrILwwTGZGPTyquevlMe3MlnAG8jfeA Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F2323E40@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Apr 2009 06:12:16.0200 (UTC) FILETIME=[2006E480:01C9BD91] X-Nokia-AV: Clean Cc: mnot@mnot.net Subject: [saag] FW: Soliciting reviews for Cross-Origin Resource Sharing X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 06:11:16 -0000 This security-related W3C document is probably of interest to SAAG subscribers. If you want to send comments to W3C, see the=20 instructions in the link below.=20 Best regards, Pasi > -----Original Message----- > From: Mark Nottingham > Sent: 06 April, 2009 12:38 > To: secdir@ietf.org > Subject: [secdir] Soliciting reviews for Cross-Origin Resource Sharing >=20 > [ with my IETF/W3C Liaison hat on ] >=20 > Members of the WebApps WG in the W3C have brought Cross-Origin > Resource Sharing (CORS) to my attention, and asked for review/input > from IETF folks. >=20 > http://www.w3.org/TR/2009/WD-cors-20090317/ >=20 > > This document defines a mechanism to enable client-side cross-origin > > requests. Specifications that want to enable cross-origin requests > > in an API they define can use the algorithms defined by this > > specification. If such an API is used on http://example.org > > resources, a resource on http://hello-world.examplecan opt in using > > the mechanism described by this specification (e.g., specifying > > Access-Control-Allow-Origin: http://example.org as response header), > > which would allow that resource to be fetched cross-origin from > > http://example.org . >=20 > The document's status section contains information about how to > provide feedback to them. >=20 > I know that generally the security directorate review process is for > review of IETF documents, but this document does have the potential > for impacting IETF technologies, and is directly security-related. If > the directorate is unable to provide a review, please forward this to > the appropriate folks in the IETF security community who may be > interested in providing individual reviews and feedback to the WG. >=20 > Cheers, >=20 > -- > Mark Nottingham http://www.mnot.net/ From housley@vigilsec.com Mon Apr 20 13:16:11 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16753A69A9 for ; Mon, 20 Apr 2009 13:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.511 X-Spam-Level: X-Spam-Status: No, score=-101.511 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_20=-0.74, USER_IN_WHITELIST=-100] 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 1SttPyZIMt+M for ; Mon, 20 Apr 2009 13:16:11 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 64BEE3A6FD7 for ; Mon, 20 Apr 2009 13:15:39 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 5EB829A472E for ; Mon, 20 Apr 2009 16:16:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id DjrQKvi1wSbY for ; Mon, 20 Apr 2009 16:16:54 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-71-191-197-15.washdc.fios.verizon.net [71.191.197.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A4F5B9A472A for ; Mon, 20 Apr 2009 16:16:56 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 20 Apr 2009 16:16:51 -0400 To: saag@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090420201656.A4F5B9A472A@odin.smetech.net> Subject: [saag] FCC Communications Security, Reliability, and Interoperability Council X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:16:11 -0000 This may be of interest to some people on this list. Russ = = = = = = = = = The FCC said it is seeking nominations and expressions of interest for membership on the Communications Security, Reliability, and Interoperability Council, which provides guidance and expertise on communications infrastructure and public safety communications. The FCC last month renewed the charter for the council through March 18, 2011. Interested parties should send nominations or expressions of interest by May 11. Acting Chairman Michael Copps has moved to reinvigorate a number of advisory committees since he took charge in January. Key advisory panels like the North American Numbering Council had largely languished under predecessor Kevin Martin. "Copps does seem to favor bringing in the private sector and experts to help solve problems and to amplify the FCC's own expertise," said a regulatory attorney Friday. "He has said that ... he clearly wants to get things jumpstarted." Copps also feels a "comfort level" that the time is ripe to relaunch some of the advisory committees given that the DTV transition appears to be going well, the attorney said. From eran@hueniverse.com Thu Apr 23 01:04:25 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7976B28C6C7 for ; Thu, 23 Apr 2009 01:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=-0.786, 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 U7dOLATNcLID for ; Thu, 23 Apr 2009 01:04:24 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 884E228C6C6 for ; Thu, 23 Apr 2009 01:04:24 -0700 (PDT) Received: (qmail 1584 invoked from network); 23 Apr 2009 08:05:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 23 Apr 2009 08:05:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 23 Apr 2009 01:05:22 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.net" Date: Thu, 23 Apr 2009 01:05:37 -0700 Thread-Topic: OAuth Security Advisory Thread-Index: AcnD6kj7m9+F8r8FSYWHGlWnMLDamA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72342509B881FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ApXy BnzK E90I F1ri ImpX KvU/ K3Yy NEAF NwJC PGz1 QpTr Q+0S RYct TSho V8Cr WTW4; 2; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG4AZQB0ADsAcwBhAGEAZwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {29E4A6E4-FADC-4E6F-9DD8-E97EAAA2BA39}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Thu, 23 Apr 2009 08:05:37 GMT;TwBBAHUAdABoACAAUwBlAGMAdQByAGkAdAB5ACAAQQBkAHYAaQBzAG8AcgB5AA== x-cr-puzzleid: {29E4A6E4-FADC-4E6F-9DD8-E97EAAA2BA39} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 23 Apr 2009 08:23:09 -0700 Cc: "saag@ietf.org" Subject: [saag] OAuth Security Advisory X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 08:04:25 -0000 Over the past few days a security threat has been identified in the OAuth C= ore 1.0 protocol. While this is not an IETF protocol, it is being chartered= for standardization within the IETF. Before the security threat has been d= isclosed, the community has been working closely with many vendors to coord= inate and help them mitigate the risks involved. The attack cannot be solve= d without a protocol change. The OAuth Security Advisory 2009.1 was posted on the OAuth site: http://oauth.net/advisories/2009-1 For more information on the attack: http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-f= ixation-attack.html I serve as the community coordinator for this issue. Please feel to contact= me in public or private with any concerns. EHL From Pasi.Eronen@nokia.com Mon Apr 27 05:56:34 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5548B28C121 for ; Mon, 27 Apr 2009 05:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 t0FoE3Ha2i2a for ; Mon, 27 Apr 2009 05:56:33 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 5A30F28C107 for ; Mon, 27 Apr 2009 05:56:33 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3RCvb9e007021 for ; Mon, 27 Apr 2009 07:57:55 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 15:57:40 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 15:57:40 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 15:57:33 +0300 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 27 Apr 2009 14:57:33 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Mon, 27 Apr 2009 14:57:33 +0200 From: To: Date: Mon, 27 Apr 2009 14:57:31 +0200 Thread-Topic: Draft liaison response to ITU-T re: top 100 security standards Thread-Index: AcnHN7oi2+W+TnxuTrGUhHPE2iVJvQ== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F246D0AC@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Apr 2009 12:57:33.0517 (UTC) FILETIME=[BB3BFFD0:01C9C737] X-Nokia-AV: Clean Subject: [saag] Draft liaison response to ITU-T re: top 100 security standards X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 12:56:34 -0000 Hi all, A while back we received a liaison statement from ITU-T titled "Solicitation of interest in ITU-T SG 17 initiative on business use=20 of telecommunications/ICT security standards". The liaison statement=20 is available here: https://datatracker.ietf.org/liaison/511/ Tim and I have started preparing a response, basically listing bunch of IETF security standards the Study Group might consider for including in their list (note that the intent was *not* to list all possible IETF security standards). The current draft text is included=20 below. If you have any comments, or are interested in contributing to the liaison statement text, please send email to Tim and me within two weeks. =20 Best regards, Pasi & Tim ---draft text begins--- The Internet Engineering Task Force (IETF) Security Area would like to=20 thank ITU-T Study Group 17 for the opportunity to comment on the new=20 activity, "Business use of telecommunications/ICT security standards". The IETF has developed a number of security standards that could be included in this document based on the Study Group's proposed criteria. An initial list is provided below (in alphabetical order): * Cryptographic Message Syntax (CMS) * DNS Security (DNSSEC) * DomainKeys Identified Mail (DKIM) * Extensible Authentication Protocol (EAP) framework and=20 authentication methods * Generic Security Service Application Program Interface (GSS-API)=20 framework and mechanisms * HTTP authentication mechanisms and HTTP cookies * IPsec * Internet X.509 Public Key Infrastructure (PKIX) certificate=20 profiles and protocols * Kerberos * Lightweight Directory Access Protocol (LDAP)=20 * Remote Authentication Dial In User Service (RADIUS) and Diameter * S/MIME and OpenPGP=20 * Secure Real-time Transport Protocol (SRTP) * Secure Shell (SSH) * Simple Authentication and Security Layer (SASL) framework and mechanisms * Transport Layer Security (TLS) The IETF Security Area does not have the resources to directly support this activity, but IETF protocol experts may be willing to assist in the development of summary sheets for specific protocols. We would invite Study Group 17 to contact the IETF Working Group responsible for the protocol for assistance if required. ---draft text ends--- From paul.hoffman@vpnc.org Mon Apr 27 07:53:22 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FFB93A6F3B for ; Mon, 27 Apr 2009 07:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 wa0acDpPqX8m for ; Mon, 27 Apr 2009 07:53:21 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F2A0B3A6E22 for ; Mon, 27 Apr 2009 07:53:20 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3REscT5038203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 07:54:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F246D0AC@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F246D0AC@NOK-EUMSG-01.mgdnok.nokia.com> Date: Mon, 27 Apr 2009 07:54:37 -0700 To: , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [saag] Draft liaison response to ITU-T re: top 100 security standards X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 14:53:22 -0000 At 2:57 PM +0200 4/27/09, wrote: >Tim and I have started preparing a response, basically listing bunch >of IETF security standards the Study Group might consider for >including in their list (note that the intent was *not* to list all >possible IETF security standards). The current draft text is included >below. That list seems fine (maybe with a bit of extension), but there are also questions in their request. The first question they ask is "Do you agree that this work activity would be useful to organizations and/or DC/CETs planning to deploy telecommunications/ICT security systems?". You might consider answering that question and, if you do, say "no". It is hard to imagine that an organization in any part of the world, not just in DC/CETs, would find a list of 100 security standards in the least bit useful. --Paul Hoffman, Director --VPN Consortium From Pasi.Eronen@nokia.com Wed Apr 29 23:03:49 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742F73A6F38; Wed, 29 Apr 2009 23:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 XgzS8Aa5155J; Wed, 29 Apr 2009 23:03:48 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AAE9D3A6DE7; Wed, 29 Apr 2009 23:03:47 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3U64cYm002826; Thu, 30 Apr 2009 09:05:03 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 09:05:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 09:04:56 +0300 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 30 Apr 2009 08:04:56 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Thu, 30 Apr 2009 08:04:50 +0200 From: To: , Date: Thu, 30 Apr 2009 08:04:48 +0200 Thread-Topic: Pasi's AD Notes for April 2009 Thread-Index: AcnJWZGT/WyCswKLQYqAEVzqNZlasA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F24D4D82@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Apr 2009 06:04:56.0860 (UTC) FILETIME=[965B2DC0:01C9C959] X-Nokia-AV: Clean Subject: [saag] Pasi's AD Notes for April 2009 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 06:03:49 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - Edited and posted SAAG minutes - We have received a liaison statement from ITU-T SG 17; I and Tim=20 are preparing a response (sent to SAAG list for comments) - Deployed some new code for datatracker.ietf.org, more=20 coming soon... - Some CSS etc. work for the IETF website redesign - IESG will meet face-to-face on May 11-12 - (not wearing AD hat): Errata #1628 (for RFC 4742): waiting for NETCONF WG chairs/Dan to confirm this [since 2009-02-26] WORKING GROUPS DKIM - draft-ietf-dkim-rfc4871-errata: in IETF Last Call (ends 2009-05-08) - draft-ietf-dkim-overview: in IETF Last Call (ends 2009-05-08) - draft-ietf-dkim-ssp: waiting for the WG to converge on text for Section 2.7. - Waiting for WG to send list of RFC errata IDs (the non-controversial ones, not related to d=3D/i=3D) the WG agrees on. EMU - Quiet month IPSECME - Virtual interim meeting scheduled for 2009-05-05 - Some cleaning/fixing of IANA registries for IPsec/IKEv1/IKEv2 - Looking into fixing the IANA registrations of RFC 4543; I have the token to send email to WG list. - (not wearing hats) draft-ietf-ipsecme-ikev2-ipv6-config: I promised to update the draft (clean it, address TBDs) so it would be ready=20 for WGLC (as Experimental) if this path is chosen by WG. ISMS - draft-ietf-isms-secshell, draft-ietf-isms-tmsm, and draft-ietf-isms-transport-security-model, draft-ietf-isms-radius-usage:=20 went through IETF Last Call, on the agenda of the 2009-05-07 IESG=20 telechat. - Discussions about rechartering; waiting for concrete proposal =20 from David/Jeff/Wes/etc. KEYPROV - I need to catch up with the latest emails... PKIX - draft-ietf-pkix-rfc4055-update: in RFC Editor queue, waiting for 3281update draft (not a normative reference, but authors preferred it this way). SASL - Lot of emails about SCRAM/GS2 SYSLOG - draft-ietf-syslog-sign: waiting for the authors to propose text for the remaining issue [since 2009-04-06] TLS - Hoping to get Publication Request for draft-ietf-tls-extractor soon... - (not WG items) Two IPR disclosures related to draft-badra-hajjeh-mtls and draft-badra-tls-multiplexing - (not WG item yet) Apparently some folks are interested in getting draft-rescorla-tls-extended-random published (and an implementation exists). I was hoping to see a presentation in San Francisco, but that didn't happen -- perhaps something happens on the mailing list. - (not WG item yet) I need to talk with the chairs and Michael about what to do with Mobi-D OTHER DOCUMENTS - draft-lebovitz-kmart-roadmap: I need to read this and=20 comment/contribute. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. DISCUSSES (active -- something happened within last month) - draft-atlas-icmp-unnumbered: waiting for authors to reply to my comments [since 2009-04-21] - draft-ietf-dime-mip6-split: text ok, waiting for Dan to re-do the IETF last call [since 2009-04-28] - draft-ietf-ipfix-file: waiting for authors to reply to my comments [since 2009-04-23] - draft-ietf-l2tpext-tdm: waiting for Ralph to re-do the IETF=20 last call [since 2009-04-21] - draft-ietf-lemonade-streaming: I think we have rough agreement on the changes; waiting for the authors to submit a revised ID=20 [since 2009-04-28] - draft-ietf-ntp-ntpv4-proto: waiting for authors to reply to my email or submit a revised ID [since 2009-04-16] - draft-ietf-radext-management-authorization: changes agreed, waiting for authors to submit a revised ID [since 2009-04-20] - draft-ietf-softwire-security-requirements: text agreed, waiting for authors to submit a revised ID [since 2009-04-27] - draft-igoe-secsh-aes-gcm: waiting for Tim to conclude what changes are needed to the draft [latest email 2009-04-21] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-ietf-bfd-base: text agreed, waiting for authors to submit=20 a revised ID [since 2009-03-19] - draft-ietf-ospf-lls: version -07 did not address my comments; waiting for a revised ID or RFC Editor Notes [since 2009-03-19] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cain-post-inch-phishingextns: authors have promised a new version some time in February [since 2009-01-29] - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-07] (but talked briefly with Radia at IETF74) - draft-ietf-sip-xcapevent: waiting for revised ID or RFC Editor Note to fix the ABNF/XML bugs [since 2008-10-24] - draft-ietf-sipping-policy-package: waiting for more information from Mary or Jon [since 2008-10-28] --end--