From saag-bounces@ietf.org Wed Oct 1 22:57:31 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F043A68AE; Wed, 1 Oct 2008 22:57:31 -0700 (PDT) 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 C24F83A68BD for ; Tue, 30 Sep 2008 15:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTmZYOVVFBm1 for ; Tue, 30 Sep 2008 15:38:36 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1C3093A68A3 for ; Tue, 30 Sep 2008 15:38:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,340,1220227200"; d="scan'208";a="105623592" Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-3.cisco.com with ESMTP; 30 Sep 2008 22:38:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id m8UMcNjm011188; Tue, 30 Sep 2008 15:38:23 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8UMcNs4000495; Tue, 30 Sep 2008 22:38:23 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 15:38:23 -0700 Received: from [171.69.75.172] ([171.69.75.172]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 15:38:23 -0700 In-Reply-To: <1696498986EFEC4D9153717DA325CB7201C311C7@vaebe104.NOE.Nokia.com> References: <224856.81582.qm@web31809.mail.mud.yahoo.com> <1696498986EFEC4D9153717DA325CB7201C311C7@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Paul Gleichauf Date: Tue, 30 Sep 2008 15:38:28 -0700 To: X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 30 Sep 2008 22:38:23.0212 (UTC) FILETIME=[3EEFB2C0:01C9234D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12202; t=1222814303; x=1223678303; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pgleicha@cisco.com; z=From:=20Paul=20Gleichauf=20 |Subject:=20Re=3A=20[saag]=20Content=20rights=20management= 20(was=3A=20Pasi's=20AD=20notes=20for=20September=202008) |Sender:=20; bh=Lsb5ZxQxSNQmPVzt1xwNuLF981vti09N8x1YyKIaDrc=; b=Y1l7sOol5C+c02tMydStdHwDmenGYIYFUZZYkfHyNz8mGy+qwiVjIjxorc suv4SKm/DjyCQFH0ddIyjIWGAlUrEoCvF+FZ6eN6NT6tx9vWMHOGMKJNjU4G IWNXkSqOyx; Authentication-Results: sj-dkim-5; header.From=pgleicha@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Mailman-Approved-At: Wed, 01 Oct 2008 22:57:31 -0700 Cc: Paul Gleichauf , saag@ietf.org Subject: Re: [saag] Content rights management (was: Pasi's AD notes for September 2008) 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org The term "data leakage" is often used to describe the management of = confidential information within and across Enterprises. Such systems = tend to be preventative in character rather than secure against = malicious behaviors. The On Sep 30, 2008, at Sep 30, 20082:52 PM, wrote: > Thomas, > > If I remember the history correctly, the IDRM and PERM BOFs were about > DRM for copyright enforcement, or managing rights for entertainment > content that is usually publicly available (to anyone who pays). As > you point out, this is an area where several other organizations have > also been active (not very successfully, some folks might say), and > I don't think IETF work in this area would have much chances either. > > However, this BOF proposal is about managing rights for *confidential* > information (inside an enterprise, or between cooperating = > enterprises); > some folks are using the term "data-centric security" to mean = > something > similar. > > This topic has received perhaps less attention (although e.g. = > Microsoft > Office has related features), and there are some differences. For > example, entertainment DRM often considers the user to be the = > adversary, > but inside an enterprise, most users aren't actively trying to leak > confidential information to competitors. Also, entertainment DRM is > usually "break once, run anywhere", so if it works only 50% of time, > it's useless -- but preventing 50% of information leaks could be > worthwhile. > > Even this kind of "rights management" is a somewhat controversial > topic (especially if used outside enterprise scenarios), and = > personally, > I have some doubts whether we at IETF have the right set of people > (e.g., vendors, potential users, etc.) for this work (and it's not > clear what "this work" even is). However, I think the topic is > sufficiently different from entertainment DRM that it might succeed > somewhere (even if it turns out IETF wasn't the right place). > > Unlike Paul (who replied to you already), I might even consider going > to the bar BOF, if it happens and they have good beer :-) However, > I want to clarify that the IETF is *not* proposing anything here -- > a bar BOF is just individuals chatting over drinks. > > Best regards, > Pasi > >> -----Original Message----- >> From: ext Thomas Hardjono [mailto:thardjono@yahoo.com] >> Sent: 30 September, 2008 21:28 >> To: saag@ietf.org; secdir@mit.edu; Eronen Pasi (Nokia-NRC/Helsinki) >> Cc: Mark Baugher; thardjono@yahoo.com >> Subject: Re: [saag] Pasi's AD notes for September 2008 >> >> >> >> Pasi, Tim, >> >> Apologies for asking, but I was wondering about the proposed >> Content Rights Management (ie. DRM) BOF. More specifically, I >> was wondering if the IETF is now open to discussing such a >> "DRM standard". >> >> Back in 2001, Mark Baugher and myself went through two (2) >> BOFs proposing the creation of an IETF open standards for a >> DRM protocol. If my memory serves me right the presiding ADs >> was Steve Bellovin and Russ Housley. The specific protocol >> was called PERM, and the slides can be found here: >> http://hardjono.net/idrm/ >> >> At that time the outcry against this effort was deafening. I >> was arguing that it was better for the IETF to own such a >> protocol and made it it "open" (ie. not proprietary and no >> need to sign consortium legal paperwork). Since that time >> there has been a plethora of DRM related products and >> standards (eg. Apple, MSFT RM, OMA-download, CableLabs, 5C, >> etc, etc). In a sense, the IETF missed the boat on this one. >> >> Not that I'm unsupportive, but I was wondering what is >> motivating the IETF to propose such a BOF again at this time :) >> >> Thanks. >> >> Regards. >> >> /thomas/ >> >> --- On Tue, 9/30/08, Pasi.Eronen@nokia.com >> wrote: >> >>> From: Pasi.Eronen@nokia.com >>> Subject: [saag] Pasi's AD notes for September 2008 >>> To: saag@ietf.org, secdir@mit.edu >>> Date: Tuesday, September 30, 2008, 3:21 AM >>> Hi all, >>> >>> 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 >>> >>> - There have been two security-related BoF requests for >>> IETF73: >>> OAuth (in the applications area), and Content Rights >>> Management >>> (in the security area). For the latter, Tim and I have >>> recommended >>> having a bar BoF first. >>> - SecDir mailing list is in the process of being moved from >>> mit.edu >>> to ietf.org servers. >>> - I've spent some time this month on tools development >>> and IESG >>> process improvements -- nothing is ready yet, but >>> hopefully soon.. >>> >>> WORKING GROUPS >>> >>> DKIM >>> - draft-ietf-dkim-ssp: in Publication Requested, waiting >>> for >>> me to read it. >>> - Waiting for WG to send list of RFC errata IDs the WG >>> agrees on. >>> >>> EMU >>> - draft-ietf-emu-gpsk: in AD Evaluation -- waiting for >>> revised >>> ID that reflects the new WG consensus on MAC length/key >>> size >>> issue before going to IETF last call (since 2008-08-25) >>> - A liaison statement reply was sent to ITU-T SG 17 >>> regarding X.1034, >>> "Guidelines on EAP-based authentication and key >>> management in a >>> data communication network". >>> - IESG appointed Joe Salowey as the designated expert for >>> IANA >>> allocation of EAP Type Codes >>> - (not WG item) draft-arkko-eap-aka-kdf =EDs now in IETF >>> Last Call >>> >>> IPSECME >>> - Lots of emails that I need to read (but haven't done >>> so yet) >>> - (not wearing AD hat) I sent my "things that need to >>> be looked at" >>> list about IKEv2bis to the mailing list; I need to check >>> that >>> they got entered in the issue tracker, too. >>> >>> ISMS >>> - It seems the discussion has largely converged; I'm >>> waiting for >>> revised IDs to read and review. >>> >>> KEYPROV >>> - I sent more comments regarding PSKC; I need to read the >>> replies >>> and participate in discussion. >>> - I need to review and comment DSKPP, too. >>> >>> SASL >>> - I replied to Frank Ellermann's appeal about WG >>> chairs' handling >>> of draft-ietf-sasl-crammd5. >>> - Waiting for charter update text from the chairs (>6 >>> months) >>> >>> SYSLOG >>> - draft-ietf-syslog-transport-tls: a revised version >>> addressing >>> Chris Newman's DISCUSS should be posted in a couple >>> of days. >>> - draft-ietf-syslog-sign: there has been a bunch of replies >>> to my >>> AD evaluation comments that I need to read and process, >>> but I >>> haven't done so yet. >>> >>> TLS >>> - (not WG item) draft-rescorla-tls-suiteb is now in IETF >>> Last Call. >>> - (not WG item) draft-hajjeh-tls-identity-protection: IESG >>> reviewed >>> this independent submission to the RFC Editor, and >>> recommended >>> not publishing it. >>> >>> OTHER DOCUMENTS >>> >>> - draft-ietf-capwap-*: I've been working with Pat and >>> others, >>> and I think we're done (except that agreed text needs >>> to be >>> edited in, and some editorial nits fixed). >>> - draft-ietf-avt-rtcpssm: no news; waiting for Joerg to >>> explore >>> "feedback debug" messages. >>> - draft-santesson-digestbind: I read this and sent comments >>> to >>> Stefan. >>> - PKCS #1/RFC 3447 update: waiting for James Randall to >>> post an >>> update including the various errata. >>> - draft-mattsson-srtp-store-and-forward: I've promised >>> to read >>> this and send comments, but haven't done so yet. >>> - draft-ietf-mpls-mpls-and-gmpls-security-framework: >>> I've promised >>> to read this once there's a new version. >>> - "Security roadmap for routing protocols": >>> I've promised to read >>> and comment this once Gregory sends something. >>> >>> DISCUSSES (active -- something happened within last month) >>> >>> - draft-ietf-capwap-protocol-binding-ieee80211: text >>> agreed, >>> waiting for authors to submit a revised ID [since >>> 2008-09-26] >>> - draft-ietf-lemonade-msgevent: waiting for authors to >>> submit >>> a revised ID [since 2008-09-08] >>> - draft-ietf-mip6-whyauthdataoption: waiting for authors to >>> submit >>> a revised ID [since 2008-09-08] >>> - draft-ietf-mipshop-mstp-solution: the authors have >>> replied to >>> my comments; I need to read the replies [since >>> 2008-09-26] >>> - draft-ietf-nfsv4-rpcsec-gss-v2: waiting for authors to >>> reply to my comments [since 2008-09-25] >>> - draft-ietf-sieve-refuse-reject: waiting for authors to >>> reply >>> to my comments [since 2008-09-11] >>> - draft-ietf-sipping-race-examples: waiting for document >>> shepherd >>> or Jon to comment the "Updates" issue [since >>> 2008-09-26] >>> - draft-ietf-v6ops-addcon: the changes in version -10 were >>> sent >>> to 6MAN WG for review; I'll clear once this has >>> happened >>> [expected to happen on 2008-10-01] >>> - draft-mraihi-inch-thraud: version -07 addressed almost >>> all of >>> my comments; waiting for authors to send RFC Editor Note >>> text >>> fixing the IANA issue, too [since 2008-09-02] >>> >>> DISCUSSES (stalled -- I haven't heard anything from the >>> authors >>> or document shepherd for over one month) >>> >>> - draft-cain-post-inch-phishingextns: waiting for authors >>> to reply >>> to my comments or submit a revised ID [since 2008-08-28] >>> - draft-cam-winget-eap-fast-provisioning: waiting for >>> authors to >>> reply to my comments or submit a revised ID [since >>> 2008-08-28] >>> - draft-hautakorpi-sipping-uri-list-handling-refused: text >>> agreed, >>> waiting for authors to submit a revised ID [since >>> 2008-07-03] >>> - draft-ietf-enum-experiences: talked briefly with Jon >>> Peterson >>> in Dublin -- waiting to hear more from the authors and/or >>> Jon >>> [since 2008-07-31] >>> - draft-ietf-pce-pcep: new version -15 addressed some >>> comments from >>> other ADs; some discussions about my comments has >>> occured; >>> waiting for proposed text or revised ID [since >>> 2008-06-16] >>> - draft-ietf-pwe3-pw-atm-mib: waiting for authors to reply >>> to >>> my comments or submit a revised ID [since 2008-07-02] >>> - draft-zhou-emu-fast-gtc: changes probably agreed, waiting >>> for authors >>> to submit a revised ID to see exact text [since >>> 2008-08-28] >>> >>> DISCUSSES (presumed dead -- I haven't heard anything >>> from the authors >>> or document shepherd for over three months) >>> >>> - draft-ietf-bfd-base: waiting for authors to reply to my >>> comments or submit a revised ID [since 2008-06-05] >>> - draft-ietf-bfd-multihop: waiting for authors to reply to >>> my comments or submit a revised ID [since 2008-06-05] >>> - draft-ietf-bfd-v4v6-1hop: waiting for authors to reply to >>> >>> my comments or submit a revised ID [since 2008-06-05] >>> - draft-ietf-shim6-proto: waiting for Erik to propose >>> something >>> to solve IPsec interaction issue [since 2008-06-18] >>> - draft-ietf-simple-imdn: waiting for authors to reply to >>> my >>> comments or submit a revised ID [since 2008-05-14] >>> - draft-ietf-sipping-sbc-funcs: new version (-06) addressed >>> all comments except one; text agreed for the remaining >>> one, >>> waiting for RFC editor note or revised ID [since >>> 2008-06-17] >>> - draft-ietf-tsvwg-emergency-rsvp: this document has large >>> number of discusses/abstains; waiting for Magnus to >>> figure >>> out next steps [since 2008-06-03] >>> >>> --end-- >>> _______________________________________________ >>> 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 _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 00:14:46 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DBE3A6AD7; Fri, 3 Oct 2008 00:14:46 -0700 (PDT) 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 7D8EE3A6ADD; Fri, 3 Oct 2008 00:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 q4XCCT-+pIgY; Fri, 3 Oct 2008 00:14:44 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id F38633A6ACB; Fri, 3 Oct 2008 00:14:43 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m937F0NH031897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Oct 2008 10:15:00 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> From: Lars Eggert To: ext Joe Touch , "Steven M. Bellovin" , draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman In-Reply-To: <48E5712B.8020305@isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 3 Oct 2008 10:15:00 +0300 References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8372/Thu Oct 2 18:21:47 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Fri, 03 Oct 2008 10:15:04 +0300 (EEST) Cc: TSV Area , saag@ietf.org Subject: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: multipart/mixed; boundary="===============1635327247==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============1635327247== Content-Type: multipart/signed; boundary=Apple-Mail-11--102235343; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-11--102235343 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, we've decided to migrate the discussion of draft-stjohns-sipso and its intersection with transport protocols to the SEC and TSV area lists. The draft is at http://tools.ietf.org/html/draft-stjohns-sipso: Common Architecture Label IPv6 Security Option (CALIPSO) This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level secure (MLS) networking environments that are both trusted and trustworthy. For those of you who haven't followed the discussion so far on the main IETF list, Section 7.3 of this draft proposes that TCP and SCTP connections are now uniquely identified by a five-tuple consisting of source and destination IP addresses and ports as well as the sensitivity label. This is obviously a pretty significant architectural change that deserves discussion, especially since the deployment of this security label architecture is likely to be very limited. Lars --Apple-Mail-11--102235343 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAwMzA3MTUwMFowIwYJKoZI hvcNAQkEMRYEFMENyLCuKEXlIkBHLu4zJ3vF9nugMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQBCxE7AKS+1OH0a420qVlDG1LrP p5aHrqivBSis9R2PoPqta2ND9eLCQhln4pk/8H7UEbMS1C+NM6/q5AAWXC+5EdhBKVrZP7TQvjPW a2GZwmo6Y2iMbqlVuPrBZC64rNhc6gZG4L6D9F9SGxXBQbonJVNvYw6G57D/vTVY70sLpi1xVy7W 5PU1Vz68Tke8nTXJoDO0T2VdEaxsmIsNFpNJr/5s/jKEbJwQlW7igfEUCU5/4EgXZLAClVPxVlLT Qf4J0v5QMM/9ECldrRux1299GUCi+u2tfWTO9iJ0MjkBPwEKx/fdY7GYt4hTgJN4cwAyNC3vWrvo eF8mTK9xL+2yAAAAAAAA --Apple-Mail-11--102235343-- --===============1635327247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1635327247==-- From saag-bounces@ietf.org Fri Oct 3 06:12:20 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01BF928C0DB; Fri, 3 Oct 2008 06:12:20 -0700 (PDT) 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 E709828C0CE; Fri, 3 Oct 2008 06:12:18 -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 It+V3bpsG87c; Fri, 3 Oct 2008 06:12:15 -0700 (PDT) Received: from eastrmmtao105.cox.net (eastrmmtao105.cox.net [68.230.240.47]) by core3.amsl.com (Postfix) with ESMTP id B721828C0D6; Fri, 3 Oct 2008 06:12:14 -0700 (PDT) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20081003131241.TUEE23768.eastrmmtao105.cox.net@eastrmimpo01.cox.net>; Fri, 3 Oct 2008 09:12:41 -0400 Received: from [10.30.20.71] ([68.0.28.112]) by eastrmimpo01.cox.net with bizsmtp id NDCg1a0052R7naU02DCgAZ; Fri, 03 Oct 2008 09:12:40 -0400 X-Authority-Analysis: v=1.0 c=1 a=_pGj05ptc1IA:10 a=k7NU11mkITEA:10 a=btbYD2SB1LsdxL1gVyEA:9 a=RWp-qRbVJxChEf0ZKGkA:7 a=uYDGmxd8keVkLtRRuE13LCcNFeMA:4 a=UmnohBiOdKAA:10 a=WuK_CZDBSqoA:10 X-CM-Score: 0.00 Message-Id: <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> From: RJ Atkinson To: Lars Eggert In-Reply-To: <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 3 Oct 2008 09:12:39 -0400 References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> X-Mailer: Apple Mail (2.929.2) Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On 3 Oct 2008, at 03:15, Lars Eggert wrote: > For those of you who haven't followed the discussion so far on the > main IETF list, Section 7.3 of this draft proposes that TCP and SCTP > connections are now uniquely identified by a five-tuple consisting of > source and destination IP addresses and ports as well as the > sensitivity label. Hi, There appear to be several points of confusion within Lars' note. Please let me try to clarify what the draft actually says and doesn't say: 0) Background about MLS operating systems: I think a major point of confusion relates to multi-level secure (MLS) operating systems, which most IETF folks have never encountered and many have never even heard about. In an MLS operating system, the OS provides mandatory access controls that separate users and data according to a lattice. Users have "clearances", while data have "sensitivity labels". These labels primarily are two dimensional. One traditionally thinks of a vertical axis consisting (bottom to top) as: System Low, Unclassified, Secret, Most Secret, System High. One traditionally thinks of a horizontal axis consisting of various compartments (e.g. NATO, UK, RU). The OS ensures that users with lower clearances are not even aware of the existence of data outside their clearance. 1) No change is proposed to TCP in general: There is *no* proposal to change how TCP or SCTP connections are identified or implemented for any system that does NOT claim to implement this MLS label specification. 2) MLS operating systems have different requirements: In turn, this specification *only* applies to Multi-Level Secure (MLS) operating systems that choose to implement this particular IPv6 labelling specification. The draft is very clear about this. 3) The MLS-specific proposal is accepted by long-term members of the Transport community: Please see Dave Borman's note to the IETF discuss list from yesterday. Dave has about as much TCP experience as anyone. 4) Nothing new is being proposed for the transport layer: This shipped about 20 years ago. So we have about 20 years of operational experience that the description in this draft is correct for an MLS operating system. Circa 1992, MLS operating systems that implemented TCP in this way for IPv4 included at least: Digital Ultrix CMW IBM Trusted AIX SGI Trusted IRIX Sun CMW As of now, some of those folks have left the MLS OS business, but I believe existing MLS operating systems as of today that do this include at least: Trusted Linux (only if configured with an MLS policy) Sun Trusted Solaris I'm not as knowledgable about MULTICS as others here (e.g. Mike StJohns), but one imagines that MULTICS also had this approach within its TCP when MULTICS was deployed with an MLS policy enabled. > This is obviously a pretty significant > architectural change that deserves discussion, > especially since the > deployment of this security label architecture is likely to be very > limited. 5) This draft doesn't propose to change the transport architecture: The draft simply describes how existing MLS operating systems implement multi-level security requirements within the existing transport-layer architecture. This is the same implementation approach that it has been used for about 2 decades now. 6) This draft has has broad review from users who have MLS deployments and from implementers of MLS systems: The draft has existed for a couple of years now. Comments on the draft from MLS-knowledgeable users have been received from many places on several continents. Similarly, comments have been received from MLS-knowledgable implementers. Various changes have resulted from those comments and reviews. So within the MLS community there has already been significant review and consensus that this draft meets the needs for IPv6 deployments of MLS systems. Yours, Ran Atkinson rja@extremenetworks.com _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 06:58:01 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171503A69EA; Fri, 3 Oct 2008 06:58:01 -0700 (PDT) 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 41B023A69EA; Fri, 3 Oct 2008 06:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=-0.239, 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 YKcNd2Zo5ONn; Fri, 3 Oct 2008 06:57:59 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2D8B23A6859; Fri, 3 Oct 2008 06:57:59 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m93DwD8H015215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 06:58:15 -0700 (PDT) Message-ID: <48E624F5.7000203@isi.edu> Date: Fri, 03 Oct 2008 06:58:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: RJ Atkinson References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> In-Reply-To: <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, I've made several points on this matter on the original thread on the main IETF list. I'll summarize a few below, in the context of Ran's overview. RJ Atkinson wrote: > > On 3 Oct 2008, at 03:15, Lars Eggert wrote: >> For those of you who haven't followed the discussion so far on the >> main IETF list, Section 7.3 of this draft proposes that TCP and SCTP >> connections are now uniquely identified by a five-tuple consisting of >> source and destination IP addresses and ports as well as the >> sensitivity label. > > Hi, > > There appear to be several points of confusion within Lars' > note. Please let me try to clarify what the draft actually > says and doesn't say: > > 0) Background about MLS operating systems: > I think a major point of confusion relates to multi-level > secure (MLS) operating systems, which most IETF folks have > never encountered and many have never even heard about. > In an MLS operating system, the OS provides mandatory > access controls that separate users and data according to > a lattice. Users have "clearances", while data have > "sensitivity labels". These labels primarily are two > dimensional. One traditionally thinks of a vertical axis > consisting (bottom to top) as: System Low, Unclassified, > Secret, Most Secret, System High. One traditionally > thinks of a horizontal axis consisting of various compartments > (e.g. NATO, UK, RU). The OS ensures that users with lower > clearances are not even aware of the existence of data > outside their clearance. As noted in the draft, this is an update to the use of the IP security option originally defined in RFC 791. Interactions between that option and TCP were specified in RFC 793, and this document changes that behavior very dramatically. > 1) No change is proposed to TCP in general: > There is *no* proposal to change how TCP or SCTP connections > are identified or implemented for any system that does NOT > claim to implement this MLS label specification. Granted that the IP security option is not *used* except on MLS endpoints, but note that: - RFC 791 specifies that the IP security option must be implemented in all hosts and gateways; its _USE_ may be optional, but its *implementation* is not optional. - RFC 793 specifies current interaction with that option, and 1122 reinforces that interaction, which specifies behavior even when the option is not used in packets emitted by the host There appears to be at least one change that might be required by all Internet hosts; current behavior upon receipt of an IP packet at a security level not supported is to send a TCP RST. This document indicates that such hosts MUST silently drop such packets. > 2) MLS operating systems have different requirements: > In turn, this specification *only* applies to Multi-Level > Secure (MLS) operating systems that choose to implement > this particular IPv6 labelling specification. The draft > is very clear about this. The draft does not appear to indicate how an MLS system would interact with legacy systems that are not updated. > 3) The MLS-specific proposal is accepted by long-term > members of the Transport community: > Please see Dave Borman's note to the IETF discuss > list from yesterday. Dave has about as much TCP > experience as anyone. I consider it very incomplete with regard to the impact of the changes proposed on the architecture of MLS endpoints. > 4) Nothing new is being proposed for the transport layer: > This shipped about 20 years ago. So we have about 20 > years of operational experience that the description in > this draft is correct for an MLS operating system. I'm presuming that implementations prior to this update implemented the IP option handling in RFC 793 and 1122. This document changes that quite a bit. ... > 5) This draft doesn't propose to change the transport > architecture: Section 7.3.1 requires that the transport architecture for MLS endsystems uses a 5-tuple to identify TCP endpoints. That has implications across the network architecture supported by MLS endsystems. > 6) This draft has has broad review from users who have MLS > deployments and from implementers of MLS systems: - ---- Overall, my concerns are that: 1. this document needs to address interactions with non-MLS updated endpoints, and whether that needs to change 2. this document needs to explicitly indicate that it overrides RFCs 791, 793, and 1122 in allowing the implementation of changes to be optional for hosts not *using* MLS 3. this document needs a much more extensive treatment of how it changes the Internet architecture for MLS-updated hosts and gateways I remain concerned that this last item is complex, and certainly incomplete at this point. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmJPQACgkQE5f5cImnZrt0wwCg9peX02r44U4uFbpxsTDzfwYs NCkAnj8Ct62v9rsaJmyIWcSmuTlQUXEa =VnIR -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 07:40:02 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732E33A6AE2; Fri, 3 Oct 2008 07:40:02 -0700 (PDT) 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 A8CC33A69EA; Fri, 3 Oct 2008 07:40:00 -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 4vP3w0NRXN86; Fri, 3 Oct 2008 07:39:59 -0700 (PDT) Received: from eastrmmtao104.cox.net (eastrmmtao104.cox.net [68.230.240.46]) by core3.amsl.com (Postfix) with ESMTP id 4C4783A6820; Fri, 3 Oct 2008 07:39:59 -0700 (PDT) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20081003144005.IWX2096.eastrmmtao104.cox.net@eastrmimpo01.cox.net>; Fri, 3 Oct 2008 10:40:05 -0400 Received: from [10.30.20.71] ([68.0.28.112]) by eastrmimpo01.cox.net with bizsmtp id NEg41a00A2R7naU02Eg4td; Fri, 03 Oct 2008 10:40:05 -0400 X-Authority-Analysis: v=1.0 c=1 a=_pGj05ptc1IA:10 a=k7NU11mkITEA:10 a=IuCs_pEey_mV-ZFpKYIA:9 a=R0VNg1MWqZtAYn8Kk2YA:7 a=zF7bhzIIyTV2b_w427YoCnFOGCIA:4 a=UmnohBiOdKAA:10 a=WuK_CZDBSqoA:10 X-CM-Score: 0.00 Message-Id: From: RJ Atkinson To: TSV Area In-Reply-To: <48E624F5.7000203@isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 3 Oct 2008 10:40:04 -0400 References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> X-Mailer: Apple Mail (2.929.2) Cc: draft-stjohns-sipso-05@tools.ietf.org, saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On 3 Oct 2008, at 09:58, Joe Touch wrote: > As noted in the draft, this is an update to the use of the IP security > option originally defined in RFC 791. More precisely, this is an IPv6 analogue to RFC-1038, RFC-1108 and CIPSO defined in FIPS-188, each of which caused that part of RFC-791 to be deprecated. Existing MLS operating systems generally support both RFC-1108 and FIPS-188 for IPv4. The goal of this draft is to enable IPv6 to be supported in addition to IPv4 in an interoperable and openly-specified manner. >> 1) No change is proposed to TCP in general: >> There is *no* proposal to change how TCP or SCTP connections >> are identified or implemented for any system that does NOT >> claim to implement this MLS label specification. > > Granted that the IP security option is not *used* except on MLS > endpoints, but note that: > > - RFC 791 specifies that the IP security option must be > implemented in all hosts and gateways; its _USE_ may > be optional, but its *implementation* is not optional. To the extent that is true, that part of RFC-791 has been ignored for more than 20 years by both host implementers and router implementers. So far as I am aware, no deployed IP implementation has ever supported the RFC-791 security option. (There might have been some support in the early BBN routers or in MULTICS; I'm not sure about details of either of those). In the 1980s, RFC-1038 was created to support a specialised security gateway called "BLACKER" because the RFC-791 definition was not suitable. (I believe all of the BLACKER systems have been out-of-service for many many years now.) Publishing RFC-1038 deprecated RFC-791's security option. The only IP router that has had IP security option support since about 1991 is Cisco IOS, which supports only RFC-1108 and (I am told and so far as I recall from looking at the source code when I worked there) did not ever support the RFC-791 definition of the security option. On the host side, I am not aware of any non-MLS host that ever had support for the RFC-791, RFC-1038, or RFC-1108 security options. > There appears to be at least one change that might be required by all > Internet hosts; current behavior upon receipt of an IP packet at a > security level not supported is to send a TCP RST. This document > indicates that such hosts MUST silently drop such packets. *Nothing in the draft applies "to all Internet hosts".* The draft is clear that nothing in the draft applies to any system that does not claim to implement that specific draft. I can repeat that scope comment in the document more times if that helps, but it does already clearly say that in the draft. > The draft does not appear to indicate how an MLS system would interact > with legacy systems that are not updated. No changes to legacy systems are needed. >> 3) The MLS-specific proposal is accepted by long-term >> members of the Transport community: >> Please see Dave Borman's note to the IETF discuss >> list from yesterday. Dave has about as much TCP >> experience as anyone. > > I consider it very incomplete with regard to the impact of the changes > proposed on the architecture of MLS endpoints. > >> 4) Nothing new is being proposed for the transport layer: >> This shipped about 20 years ago. So we have about 20 >> years of operational experience that the description in >> this draft is correct for an MLS operating system. > > I'm presuming that implementations prior to this update implemented > the IP option handling in RFC 793 and 1122. This document changes > that quite a bit. Those existing MLS implementations were the basis for the current text in this document. They did not follow either RFC-793 or RFC-1122 in this narrow respect, to the best of my knowledge. (I have specific knowledge of kernel internals for some, but not all, of the CMW products that existed in the early 1990s.) More broadly, (single-level OS) TCP and IP implementations that are deployed today do not follow RFC-791, RFC-793, or RFC-1122 in each and every detail. For openers, I don't think any implementations of the RFC-791 security option exist. ASIDE: One of the reasons that the IETF hasn't produced either a router requirements or a host requirements document for many years is that the last attempts in those areas did not have much impact, either on what implementers shipped or on what operators deployed. >> 5) This draft doesn't propose to change the transport >> architecture: > > Section 7.3.1 requires that the transport architecture for MLS > endsystems uses a 5-tuple to identify TCP endpoints. That has > implications across the network architecture supported by MLS > endsystems. The architecture is unchanged. MLS TCP implementations do vary somewhat, as Dave Borman already noted on the IETF discuss mailing list. When one has an MLS system, conceptually one has many concurrent logically separate TCP implementations (one per sensitivity level). This draft simply describes how one maps the existing (unchanged) architecture onto an MLS OS implementation. > 1. this document needs to address interactions with non-MLS updated > endpoints, and whether that needs to change I am happy to repeat in the draft that non-MLS systems do not need to change. > 2. this document needs to explicitly indicate that it overrides RFCs > 791, 793, and 1122 in allowing the implementation of changes to be > optional for hosts not *using* MLS I can't parse that sentence, so I'm a bit confused. I'm happy to edit the document text to repeat the note that nothing in the document applies to any system that does not claim to implement the document -- if that is what you are asking for. > 3. this document needs a much more extensive treatment of how it > changes > the Internet architecture for MLS-updated hosts and gateways This draft is not a specification for building an MLS operating system, nor should it be. Some relevant references on MLS operating systems are included in the draft for those who want to learn more about MLS operating systems. Again, the Internet Architecture does not change. What does change are some implementation details within an MLS operating system (as compared with a traditional and much more common single-level OS). Yours, Ran rja@extremenetworks.com _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 08:07:04 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799313A69B5; Fri, 3 Oct 2008 08:07:04 -0700 (PDT) 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 B38E63A698F; Fri, 3 Oct 2008 08:07:03 -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=[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 7-IZHcsRvNV5; Fri, 3 Oct 2008 08:07:02 -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 8FA6F3A6968; Fri, 3 Oct 2008 08:07:01 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m93F79AI000392; Fri, 3 Oct 2008 15:07:22 GMT Received: from localhost.east.sun.com (vroom.SFBay.Sun.COM [10.7.251.192]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m93F710Q016756; Fri, 3 Oct 2008 11:07:02 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m93EWx8s022753; Fri, 3 Oct 2008 07:32:59 -0700 (PDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m93EWmga022748; Fri, 3 Oct 2008 07:32:48 -0700 (PDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Joe Touch In-Reply-To: <48E624F5.7000203@isi.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> Date: Fri, 03 Oct 2008 07:32:44 -0700 Message-Id: <1223044364.21925.20.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.23.91 Cc: TSV Area , draft-stjohns-sipso-05@tools.ietf.org, saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 2008-10-03 at 06:58 -0700, Joe Touch wrote: > There appears to be at least one change that might be required by all > Internet hosts; current behavior upon receipt of an IP packet at a > security level not supported is to send a TCP RST. This document > indicates that such hosts MUST silently drop such packets. In a securely-configured MLS environment, systems not running an MLS operating system will never receive a packet with an MLS label -- if they did, that inherently means that an MLS system somewhere is misconfigured and information is flowing in violation of the MLS policy. It is IMHO not necessary to specify what a label-unaware system should do with a labeled packet -- if they get one at all, it's a serious error on the part of the sender. > > 2) MLS operating systems have different requirements: > > In turn, this specification *only* applies to Multi-Level > > Secure (MLS) operating systems that choose to implement > > this particular IPv6 labelling specification. The draft > > is very clear about this. > > The draft does not appear to indicate how an MLS system would interact > with legacy systems that are not updated. are you asking about labeled or unlabeled interoperability? the MLS systems I'm familiar with are configured with policy indicating the clearances of other hosts. That policy can indicate whether or not packets to the other system should contain an explicit MLS label. non-MLS systems will typically never see a label. > > 3) The MLS-specific proposal is accepted by long-term > > members of the Transport community: > > Please see Dave Borman's note to the IETF discuss > > list from yesterday. Dave has about as much TCP > > experience as anyone. > > I consider it very incomplete with regard to the impact of the changes > proposed on the architecture of MLS endpoints. I have a modest amount of MLS implementation experience. I believe the spec is complete enough to publish in its current form. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 08:11:00 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001C028C1B5; Fri, 3 Oct 2008 08:10:59 -0700 (PDT) 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 19EC528C1B5; Fri, 3 Oct 2008 08:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.227, 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 UEXTY0xMaSD2; Fri, 3 Oct 2008 08:10:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 04A6F28C0EE; Fri, 3 Oct 2008 08:10:53 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m93FAh3k008453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 08:10:45 -0700 (PDT) Message-ID: <48E635F3.70308@isi.edu> Date: Fri, 03 Oct 2008 08:10:43 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: RJ Atkinson References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Ran, Thanks for the context below. Additional notes are interspersed. RJ Atkinson wrote: > > On 3 Oct 2008, at 09:58, Joe Touch wrote: ... >>> 1) No change is proposed to TCP in general: >>> There is *no* proposal to change how TCP or SCTP connections >>> are identified or implemented for any system that does NOT >>> claim to implement this MLS label specification. >> >> Granted that the IP security option is not *used* except on MLS >> endpoints, but note that: >> >> - RFC 791 specifies that the IP security option must be >> implemented in all hosts and gateways; its _USE_ may >> be optional, but its *implementation* is not optional. > > To the extent that is true, that part of RFC-791 has been > ignored for more than 20 years by both host implementers > and router implementers. > > So far as I am aware, no deployed IP implementation has ever > supported the RFC-791 security option. (There might have > been some support in the early BBN routers or in MULTICS; > I'm not sure about details of either of those). > > In the 1980s, RFC-1038 was created to support a specialised > security gateway called "BLACKER" because the RFC-791 definition > was not suitable. (I believe all of the BLACKER systems have been > out-of-service for many many years now.) Publishing RFC-1038 > deprecated RFC-791's security option. > > The only IP router that has had IP security option support > since about 1991 is Cisco IOS, which supports only RFC-1108 > and (I am told and so far as I recall from looking at the > source code when I worked there) did not ever support the > RFC-791 definition of the security option. > > On the host side, I am not aware of any non-MLS host that > ever had support for the RFC-791, RFC-1038, or RFC-1108 > security options. It would be useful to understand "support". I would not expect most deployed implementations to emit packets with that option, but I would expect deployed implementations to check that option if it was received, and match it as specified in RFC 793. >> There appears to be at least one change that might be required by all >> Internet hosts; current behavior upon receipt of an IP packet at a >> security level not supported is to send a TCP RST. This document >> indicates that such hosts MUST silently drop such packets. > > *Nothing in the draft applies "to all Internet hosts".* > > The draft is clear that nothing in the draft applies to any > system that does not claim to implement that specific draft. > > I can repeat that scope comment in the document more times > if that helps, but it does already clearly say that in the > draft. I expected to find that kind of phrase in any one of the following locations, and did not (can you point it out if I missed it?): *- the abstract *- the intro *- intent and applicability *- definition of an endsystem *- definition of an intermediate system - architecture *- defaults - format I didn't expect to see it in all locations, but certainly those with a * above. AFAICT, the assertion is made only in sections 6.2 (end system processing), and 6.3 (intermediate system processing), which is insufficient IMO. >> The draft does not appear to indicate how an MLS system would interact >> with legacy systems that are not updated. > > No changes to legacy systems are needed. It would be useful to note that in the *'d places above where the limitations of the deployment would be stated. >>> 3) The MLS-specific proposal is accepted by long-term >>> members of the Transport community: >>> Please see Dave Borman's note to the IETF discuss >>> list from yesterday. Dave has about as much TCP >>> experience as anyone. >> >> I consider it very incomplete with regard to the impact of the changes >> proposed on the architecture of MLS endpoints. >> >>> 4) Nothing new is being proposed for the transport layer: >>> This shipped about 20 years ago. So we have about 20 >>> years of operational experience that the description in >>> this draft is correct for an MLS operating system. >> >> I'm presuming that implementations prior to this update implemented >> the IP option handling in RFC 793 and 1122. This document changes >> that quite a bit. > > Those existing MLS implementations were the basis for the > current text in this document. They did not follow either > RFC-793 or RFC-1122 in this narrow respect, to the best > of my knowledge. (I have specific knowledge of kernel > internals for some, but not all, of the CMW products that > existed in the early 1990s.) > > More broadly, (single-level OS) TCP and IP implementations > that are deployed today do not follow RFC-791, RFC-793, or > RFC-1122 in each and every detail. For openers, I don't think > any implementations of the RFC-791 security option exist. Agreed, but that doesn't mean these issues don't need to be addressed. > ASIDE: > One of the reasons that the IETF hasn't produced either a > router requirements or a host requirements document for many > years is that the last attempts in those areas did not have > much impact, either on what implementers shipped or on what > operators deployed. I'm not sure I agree with that. If that's the case, then why bother with this document? I.e., if we're admitting that the Internet ignores the IETF, we can spend more time golfing ;-) >>> 5) This draft doesn't propose to change the transport >>> architecture: >> >> Section 7.3.1 requires that the transport architecture for MLS >> endsystems uses a 5-tuple to identify TCP endpoints. That has >> implications across the network architecture supported by MLS endsystems. > > The architecture is unchanged. I disagree - changing the endpoint IDs is a large change to the architecture - even if scoped to affect only MLS systems, and this needs to be addressed. > MLS TCP implementations do vary > somewhat, as Dave Borman already noted on the IETF discuss > mailing list. > > When one has an MLS system, conceptually one has many concurrent > logically separate TCP implementations (one per sensitivity level). > This draft simply describes how one maps the existing (unchanged) > architecture onto an MLS OS implementation. > >> 1. this document needs to address interactions with non-MLS updated >> endpoints, and whether that needs to change > > I am happy to repeat in the draft that non-MLS systems > do not need to change. > >> 2. this document needs to explicitly indicate that it overrides RFCs >> 791, 793, and 1122 in allowing the implementation of changes to be >> optional for hosts not *using* MLS > > I can't parse that sentence, so I'm a bit confused. > > I'm happy to edit the document text to repeat the note that > nothing in the document applies to any system that does not > claim to implement the document -- if that is what you are > asking for. I'm asking that the document explain how MLS systems' view of 793 and 1122 rules for TCP change as well. Others pointed out the potential need to "update" 793 regarding TCP changes; IMO this is needed for other network architecture docs as well. >> 3. this document needs a much more extensive treatment of how it changes >> the Internet architecture for MLS-updated hosts and gateways > > This draft is not a specification for building an MLS operating > system, nor should it be. Some relevant references on MLS > operating systems are included in the draft for those who > want to learn more about MLS operating systems. Agreed. > Again, the Internet Architecture does not change. I disagree; for MLS nodes, there are implications to ICMP processing at least, and perhaps routing, that are not addressed. These are architectural changes. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmNfMACgkQE5f5cImnZrt/yQCgzqr6ulLrYnQuNn7JSGelx0le crcAoNhBQqz3Mw0RwfMQb3IifSjV9Wa9 =gWS8 -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 08:12:52 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6AD23A6B1B; Fri, 3 Oct 2008 08:12:52 -0700 (PDT) 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 030EC3A6B05; Fri, 3 Oct 2008 08:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=-0.217, 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 O3+HoGjsV6YZ; Fri, 3 Oct 2008 08:12:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 324F03A6B04; Fri, 3 Oct 2008 08:12:50 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m93FD11w009564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 08:13:03 -0700 (PDT) Message-ID: <48E6367D.8050905@isi.edu> Date: Fri, 03 Oct 2008 08:13:01 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Bill Sommerfeld References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> In-Reply-To: <1223044364.21925.20.camel@localhost> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Sommerfeld wrote: > On Fri, 2008-10-03 at 06:58 -0700, Joe Touch wrote: > >> There appears to be at least one change that might be required by all >> Internet hosts; current behavior upon receipt of an IP packet at a >> security level not supported is to send a TCP RST. This document >> indicates that such hosts MUST silently drop such packets. > > In a securely-configured MLS environment, systems not running an MLS > operating system will never receive a packet with an MLS label -- if > they did, that inherently means that an MLS system somewhere is > misconfigured and information is flowing in violation of the MLS policy. > > It is IMHO not necessary to specify what a label-unaware system should > do with a labeled packet -- if they get one at all, it's a serious error > on the part of the sender. Serious errors occur all the time. The expected behavior of the MLS in interacting with a non-MLS endpoint should be explained *when* that happens. >>> 2) MLS operating systems have different requirements: >>> In turn, this specification *only* applies to Multi-Level >>> Secure (MLS) operating systems that choose to implement >>> this particular IPv6 labelling specification. The draft >>> is very clear about this. >> The draft does not appear to indicate how an MLS system would interact >> with legacy systems that are not updated. > > are you asking about labeled or unlabeled interoperability? Both, since you brought it up, but I was originally thinking of unlabeled. > the MLS systems I'm familiar with are configured with policy indicating > the clearances of other hosts. That policy can indicate whether or not > packets to the other system should contain an explicit MLS label. > > non-MLS systems will typically never see a label. Agreed, but (as above), this still needs to be explicit in this doc IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmNnwACgkQE5f5cImnZrvxMwCdGlmhiMSi3r3bPo0B6abiIl3X gKsAoORmH5FjuWI8MwC7L4G9hhGdoHFj =bx1E -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 08:30:42 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A5328C1FC; Fri, 3 Oct 2008 08:30:42 -0700 (PDT) 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 6BCD628C1D4; Fri, 3 Oct 2008 08:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-0.207, 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 geDMFqw+c7qc; Fri, 3 Oct 2008 08:30:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1487B28C1FC; Fri, 3 Oct 2008 08:30:13 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m93FU1Bi015965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 08:30:03 -0700 (PDT) Message-ID: <48E63A79.1020708@isi.edu> Date: Fri, 03 Oct 2008 08:30:01 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Bill Sommerfeld References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> In-Reply-To: <1223044364.21925.20.camel@localhost> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Sommerfeld wrote: > On Fri, 2008-10-03 at 06:58 -0700, Joe Touch wrote: ... >> I consider it very incomplete with regard to the impact of the changes >> proposed on the architecture of MLS endpoints. > > I have a modest amount of MLS implementation experience. I believe the > spec is complete enough to publish in its current form. If you follow the implications of " With respect to a given network, each distinct Sensitivity Label represents a separate virtual network which shares the same physical network.", and the way it impacts TCP, can you explain how the current draft indicates how to similarly virtualize any of the following? - - ICMP handling - - forwarding - - routing - - IPv6 neighbor discovery - - IGMP - - PIM - - IPsec - - IPIP tunnels - - firewalls All of these things use IP addresses as unique identifiers, and all are affected by extending that space to use the pair [address, security level] instead. Even if these changes are limited to MLS endpoints, they either need to be addressed, or the discussion of how MLS extends the endpoint needs to be revised to avoid the idea that this virtualizes the network. If the virtualization is limited to certain transport protocol connections, then that should be stated explicitly (and only). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmOnkACgkQE5f5cImnZrtDCwCfeNIU0U2uZ+6Hz/vPmAqoNpn3 RyMAn2izgUKglo5++oCC0fBTVLYhFZjN =A+Eo -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 09:15:10 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1635B28C2A4; Fri, 3 Oct 2008 09:15:10 -0700 (PDT) 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 2228028C2A4; Fri, 3 Oct 2008 09:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.446, 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 Egunwejg-rup; Fri, 3 Oct 2008 09:15:08 -0700 (PDT) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id D2FFC28C2A3; Fri, 3 Oct 2008 09:15:07 -0700 (PDT) Received: by machshav.com (Postfix, from userid 512) id 83A19AF668; Fri, 3 Oct 2008 16:15:35 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 12647AF65E; Fri, 3 Oct 2008 16:15:34 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 8D2EC838786; Fri, 3 Oct 2008 12:15:30 -0400 (EDT) Date: Fri, 3 Oct 2008 12:15:30 -0400 From: "Steven M. Bellovin" To: Bill Sommerfeld Message-ID: <20081003121530.5f686a5f@cs.columbia.edu> In-Reply-To: <1223044364.21925.20.camel@localhost> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> Organization: Columbia University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org, Joe Touch Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 03 Oct 2008 07:32:44 -0700 Bill Sommerfeld wrote: > In a securely-configured MLS environment, systems not running an MLS > operating system will never receive a packet with an MLS label -- if > they did, that inherently means that an MLS system somewhere is > misconfigured and information is flowing in violation of the MLS > policy. > > It is IMHO not necessary to specify what a label-unaware system should > do with a labeled packet -- if they get one at all, it's a serious > error on the part of the sender. > Actually, 793 disagrees: The security paramaters may be used even in a non-secure environment (the values would indicate unclassified data), thus hosts in non-secure environments must be prepared to receive the security parameters, though they need not send them. The question is how realistic that statement is. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 09:42:05 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146923A699E; Fri, 3 Oct 2008 09:42:05 -0700 (PDT) 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 B10CC3A68DB; Fri, 3 Oct 2008 09:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 AdmcuOP66tb4; Fri, 3 Oct 2008 09:42:02 -0700 (PDT) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id BFC5A3A699E; Fri, 3 Oct 2008 09:42:02 -0700 (PDT) Received: by machshav.com (Postfix, from userid 512) id 5DA57AF668; Fri, 3 Oct 2008 16:41:53 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 24371AF65E; Fri, 3 Oct 2008 16:41:52 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 5346D838786; Fri, 3 Oct 2008 12:41:49 -0400 (EDT) Date: Fri, 3 Oct 2008 12:41:48 -0400 From: "Steven M. Bellovin" To: Joe Touch Message-ID: <20081003124148.18a6a94f@cs.columbia.edu> In-Reply-To: <48E63A79.1020708@isi.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> <48E63A79.1020708@isi.edu> Organization: Columbia University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 03 Oct 2008 08:30:01 -0700 Joe Touch wrote: > If you follow the implications of " With respect to a given network, > each distinct Sensitivity Label represents a separate virtual network > which shares the same physical network.", and the way it impacts TCP, > can you explain how the current draft indicates how to similarly > virtualize any of the following? > > - - ICMP handling > - - forwarding > - - routing > - - IPv6 neighbor discovery > - - IGMP > - - PIM > - - IPsec > - - IPIP tunnels > - - firewalls > > All of these things use IP addresses as unique identifiers, and all > are affected by extending that space to use the pair [address, > security level] instead. > Without trying to answer in detail, the basic rule is simple: no data with a given security label should ever be sent to or through an entity with a different label. Routers and links are typically multi-label, so they can accept data within a range of levels. A process will always be single-level, so it can only accept data -- TCP, ICMP replies, etc. -- at exactly the same level. There are exceptions -- IPsec boxes would (in that environment) be trusted to downgrade information, i.e., accept sensitive data, encrypt it, and send out the ciphertext packets with a different label. IGMP poses a fascinating problem; I don't know that anyone has ever worked out the implications of doing that in an MLS environment. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 09:47:28 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66BF3A68DB; Fri, 3 Oct 2008 09:47:28 -0700 (PDT) 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 A8E093A68DB; Fri, 3 Oct 2008 09:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.198, 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 XgmiyoW69r3g; Fri, 3 Oct 2008 09:47:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id AB84C3A67E7; Fri, 3 Oct 2008 09:47:26 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m93GlJvp011965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 09:47:21 -0700 (PDT) Message-ID: <48E64C94.4040708@isi.edu> Date: Fri, 03 Oct 2008 09:47:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Steven M. Bellovin" References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> <48E63A79.1020708@isi.edu> <20081003124148.18a6a94f@cs.columbia.edu> In-Reply-To: <20081003124148.18a6a94f@cs.columbia.edu> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Bellovin wrote: > On Fri, 03 Oct 2008 08:30:01 -0700 > Joe Touch wrote: > >> If you follow the implications of " With respect to a given network, >> each distinct Sensitivity Label represents a separate virtual network >> which shares the same physical network.", and the way it impacts TCP, >> can you explain how the current draft indicates how to similarly >> virtualize any of the following? >> >> - - ICMP handling >> - - forwarding >> - - routing >> - - IPv6 neighbor discovery >> - - IGMP >> - - PIM >> - - IPsec >> - - IPIP tunnels >> - - firewalls >> >> All of these things use IP addresses as unique identifiers, and all >> are affected by extending that space to use the pair [address, >> security level] instead. >> > Without trying to answer in detail, the basic rule is simple: no data > with a given security label should ever be sent to or through an entity > with a different label. Routers and links are typically multi-label, > so they can accept data within a range of levels. A process will > always be single-level, so it can only accept data -- TCP, ICMP > replies, etc. -- at exactly the same level. There are exceptions -- > IPsec boxes would (in that environment) be trusted to downgrade > information, i.e., accept sensitive data, encrypt it, and send out the > ciphertext packets with a different label. IGMP poses a fascinating > problem; I don't know that anyone has ever worked out the implications > of doing that in an MLS environment. Understood; the issue is that this document, if intended to extend MLS into the architecture of MLS-enabled hosts, needs to be augmented substantially to address these issues - even if to declare some out of scope and not supported. I don't know if it's tenable to assert that only the transport protocols of interest are virtualized. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmTJMACgkQE5f5cImnZruP/ACcCyIsnvOGEsUnZAMmtd7Rclcs EkgAoM067VmD0jY4TGdrIdyQGhMwizjz =LNbL -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 10:30:59 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC3F3A6941; Fri, 3 Oct 2008 10:30:59 -0700 (PDT) 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 23EEE3A6452; Fri, 3 Oct 2008 10:30:57 -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 NLC5x8mK7MC5; Fri, 3 Oct 2008 10:30:55 -0700 (PDT) Received: from eastrmmtao103.cox.net (eastrmmtao103.cox.net [68.230.240.9]) by core3.amsl.com (Postfix) with ESMTP id 96CBE3A6AF3; Fri, 3 Oct 2008 10:30:55 -0700 (PDT) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20081003173121.XEYU22820.eastrmmtao103.cox.net@eastrmimpo02.cox.net>; Fri, 3 Oct 2008 13:31:21 -0400 Received: from [10.30.20.71] ([68.0.28.112]) by eastrmimpo02.cox.net with bizsmtp id NHXN1a0042R7naU02HXNaL; Fri, 03 Oct 2008 13:31:22 -0400 X-Authority-Analysis: v=1.0 c=1 a=_pGj05ptc1IA:10 a=k7NU11mkITEA:10 a=H-fxpU_is_q2EKUbO5EA:9 a=YJ7zj0UtSWe7uJqyBolmpdc35GYA:4 a=UmnohBiOdKAA:10 a=WuK_CZDBSqoA:10 X-CM-Score: 0.00 Message-Id: <2C9D0EA8-A48C-48E7-BF43-9948CE64D395@extremenetworks.com> From: RJ Atkinson To: TSV Area In-Reply-To: <48E635F3.70308@isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 3 Oct 2008 13:31:21 -0400 References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <48E635F3.70308@isi.edu> X-Mailer: Apple Mail (2.929.2) Cc: draft-stjohns-sipso-05@tools.ietf.org, saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On 3 Oct 2008, at 11:10, Joe Touch wrote: > It would be useful to understand "support". I would not expect most > deployed implementations to emit packets with that option, but I would > expect deployed implementations to check that option if it was > received, > and match it as specified in RFC 793. I am not aware of any non-MLS TCP/IP implementation that checks any flavour of the IPv4 security option (RFC-791, RFC-1038, or RFC-1108). So far as I know, non-MLS host implementations don't even have code to parse any flavour of the IP Security Option. I am unaware of any non-MLS TCP/IP implementation that will generate any flavour of that option. According to Stevens in "TCP/IP Illustrated, Volume 2" page 249, there is no support of any kind for the IP Security options in BSD Net/3 and later. He is silent on BSD prior to Net/3 because that book is focused on Net/3 internals. Of course, 4.4 BSD post-dates the Net/3 distribution. Cisco routers running IOS do not check the option in their default configuration. All other routers that I am aware of can not do anything with the option. (There is a small possibility that the old "Network Systems" brand routers could be configured to look at RFC-1038 or RFC-1108 labels as part of a manually configured ACL check, but there probably aren't any of those deployed now or in recent years.) Cisco routers running certain IOS versions that have been explicitly configured to do so can use the RFC-1108 IP Security Option as part of an Access Control List decision. >>> There appears to be at least one change that might be required by >>> all >>> Internet hosts; current behavior upon receipt of an IP packet at a >>> security level not supported is to send a TCP RST. This document >>> indicates that such hosts MUST silently drop such packets. >> >> *Nothing in the draft applies "to all Internet hosts".* >> >> The draft is clear that nothing in the draft applies to any >> system that does not claim to implement that specific draft. >> >> I can repeat that scope comment in the document more times >> if that helps, but it does already clearly say that in the >> draft. > > I expected to find that kind of phrase in any one of the following > locations, and did not I am quite happy to add text to the Applicability section clarifying this point. > It would be useful to note that in the *'d places above where the > limitations of the deployment would be stated. I am happy to make an edit along those lines. > Agreed, but that doesn't mean these issues don't need to be addressed. The broader question you raise of documenting which parts of RFC-791 and RFC-793 are widely not implemented is far beyond the very modest scope of this document. Such a document might well be useful, but it is well beyond the current scope. >> ASIDE: >> One of the reasons that the IETF hasn't produced either a >> router requirements or a host requirements document for many >> years is that the last attempts in those areas did not have >> much impact, either on what implementers shipped or on what >> operators deployed. > > I'm not sure I agree with that. If that's the case, > then why bother with this document? We have two specifications for IPv4 security options that have some implementation and deployment (specifically RFC-1108 and FIPS-188). These have narrow deployments in multiple geographies. Those deployments normally involve MLS operating systems. We erroneously thought we would not need an equivalent IPv6 option, but operational experience over the past decade indicates that we do need an equivalent IPv6 option. So this document fills that narrow gap (no openly specified IPv6 sensitivity label option exists). > I.e., if we're admitting that the Internet ignores the > IETF, we can spend more time golfing ;-) The above is not what I said. > I'm asking that the document explain how MLS systems' view of 793 and > 1122 rules for TCP change as well. Others pointed out the potential > need > to "update" 793 regarding TCP changes; IMO this is needed for other > network architecture docs as well. I am confused how the above would translate into a specific edit. > These are architectural changes. We appear to have different definitions for "architectural", which is perhaps not unusual for a community of this size. Yours, Ran Atkinson rja@extremenetworks.com _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 10:41:56 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415E128C191; Fri, 3 Oct 2008 10:41:56 -0700 (PDT) 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 B430F28C14C; Fri, 3 Oct 2008 10:41:54 -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 PLwK+dDUMb4e; Fri, 3 Oct 2008 10:41:54 -0700 (PDT) Received: from eastrmmtao105.cox.net (eastrmmtao105.cox.net [68.230.240.47]) by core3.amsl.com (Postfix) with ESMTP id 1747A28C1D4; Fri, 3 Oct 2008 10:40:51 -0700 (PDT) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20081003174122.YGWV23768.eastrmmtao105.cox.net@eastrmimpo01.cox.net>; Fri, 3 Oct 2008 13:41:22 -0400 Received: from [10.30.20.71] ([68.0.28.112]) by eastrmimpo01.cox.net with bizsmtp id NHhL1a00D2R7naU02HhL5a; Fri, 03 Oct 2008 13:41:20 -0400 X-Authority-Analysis: v=1.0 c=1 a=_pGj05ptc1IA:10 a=k7NU11mkITEA:10 a=QsDxGFY0CRlF82IwXnQA:9 a=dXb7MKe3Q6YQ2FqcMU9Vhzwp9CIA:4 a=UmnohBiOdKAA:10 a=WuK_CZDBSqoA:10 X-CM-Score: 0.00 Message-Id: <5AC4DA54-9B13-47AC-9734-18FAC1C3C8CD@extremenetworks.com> From: RJ Atkinson To: TSV Area In-Reply-To: <48E64C94.4040708@isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 3 Oct 2008 13:41:20 -0400 References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> <48E63A79.1020708@isi.edu> <20081003124148.18a6a94f@cs.columbia.edu> <48E64C94.4040708@isi.edu> X-Mailer: Apple Mail (2.929.2) Cc: draft-stjohns-sipso-05@tools.ietf.org, saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On 3 Oct 2008, at 12:47, Joe Touch wrote: > Understood; the issue is that this document, if intended to extend MLS > into the architecture of MLS-enabled hosts, ... It is not intended to do all that. It is just trying to specify an IPv6 Sensitivity Label. Certain implementation details need to be specified if one wants to have interoperable MLS implementations. This tries to specify only those that are really needed. Cheers, Ran rja@extremenetworks.com _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Oct 3 14:54:34 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4D403A6986; Fri, 3 Oct 2008 14:54:34 -0700 (PDT) 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 963D63A69A2; Fri, 3 Oct 2008 14:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=-0.190, 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 jNQkDCoQZUdP; Fri, 3 Oct 2008 14:54:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 84F983A6986; Fri, 3 Oct 2008 14:54:32 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m93LsgoH022206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 14:54:44 -0700 (PDT) Message-ID: <48E694A1.1080807@isi.edu> Date: Fri, 03 Oct 2008 14:54:41 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: RJ Atkinson References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <48E635F3.70308@isi.edu> <2C9D0EA8-A48C-48E7-BF43-9948CE64D395@extremenetworks.com> In-Reply-To: <2C9D0EA8-A48C-48E7-BF43-9948CE64D395@extremenetworks.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 RJ Atkinson wrote: > > On 3 Oct 2008, at 11:10, Joe Touch wrote: ... >> I'm asking that the document explain how MLS systems' view of 793 and >> 1122 rules for TCP change as well. Others pointed out the potential need >> to "update" 793 regarding TCP changes; IMO this is needed for other >> network architecture docs as well. > > I am confused how the above would translate into a specific edit. You can't just redefine TCP's notion of an endpoint. You need to address how this propagates through the protocol stack, notably: - ICMP handling does the ICMP carry the security level of the packet in its payload? does ICMP processing match the level of the incoming packet to the transport protocol? - forwarding should there be multiple forwarding entries, just as there are multiple TCPs for a socket pair? i.e., how much is the network really virtualized, or are you virtualizing only the host - and only for certain transport protocols (if so, then say that rather than virtualizing the net) - routing are there routing protocols that carry reachability only for certain levels? are those levels encoded in the routing protocol's packet headers, or in the routing protocol content (i.e., application data) itself? - similarly for multicast... - similarly for DHCP... - similarly for IPv6 neighbor discovery... - similarly for other items listed in response to Bill's email I.e., if this is really a virtual network, there's a LOT of work left to be done. If this is restricted to only TCP, then ICMP needs to be addressed (or else PMTUD won't work), at least (perhaps also DNS, e.g., SRV responses might need to be at the appropriate level as well), and the description of what is virtualized should be scoped down. (I presume the latter is where you'd prefer to go with this, though correct me if that's not the case). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmlKEACgkQE5f5cImnZrvUJACfeWmREXShZZP+aCse/V3g5gKG 6a8An0TjueMBb4WYWLIiB2yHYJ+lOgOG =Hw6t -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Oct 5 14:29:40 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BC03A67EA; Sun, 5 Oct 2008 14:29:40 -0700 (PDT) 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 13C403A67EA; Sun, 5 Oct 2008 14:29:39 -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=[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 gqX-mq9QiRbr; Sun, 5 Oct 2008 14:29:38 -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 D33813A67A5; Sun, 5 Oct 2008 14:29:36 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m95LUBli021762; Sun, 5 Oct 2008 21:30:11 GMT Received: from localhost.east.sun.com (vroom.SFBay.Sun.COM [10.7.251.192]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m95LUAhH017883; Sun, 5 Oct 2008 17:30:10 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m93HcRmh027949; Fri, 3 Oct 2008 10:38:27 -0700 (PDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m93HcQPg027946; Fri, 3 Oct 2008 10:38:26 -0700 (PDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: "Steven M. Bellovin" In-Reply-To: <20081003121530.5f686a5f@cs.columbia.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> <20081003121530.5f686a5f@cs.columbia.edu> Date: Fri, 03 Oct 2008 10:38:23 -0700 Message-Id: <1223055503.27692.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.23.91 Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org, Joe Touch Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 2008-10-03 at 12:15 -0400, Steven M. Bellovin wrote: > On Fri, 03 Oct 2008 07:32:44 -0700 > Bill Sommerfeld wrote: > > It is IMHO not necessary to specify what a label-unaware system should > > do with a labeled packet -- if they get one at all, it's a serious > > error on the part of the sender. > > > Actually, 793 disagrees: > > The security paramaters may be used even in a non-secure environment > (the values would indicate unclassified data), thus hosts in > non-secure environments must be prepared to receive the security > parameters, though they need not send them. > > The question is how realistic that statement is. As you probably would have guessed, I think it's entirely unrealistic. - Bill _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Oct 5 14:58:44 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526453A67C0; Sun, 5 Oct 2008 14:58:44 -0700 (PDT) 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 A65013A67C0; Sun, 5 Oct 2008 14:58:42 -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=[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 qtpqm7I-NNOw; Sun, 5 Oct 2008 14:58:42 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id 506BA3A67B1; Sun, 5 Oct 2008 14:58:41 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m95LxDLK028711; Sun, 5 Oct 2008 21:59:14 GMT Received: from localhost.east.sun.com (vroom.SFBay.Sun.COM [10.7.251.192]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m95LxAck028819; Sun, 5 Oct 2008 17:59:11 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m95LeNi9007006; Sun, 5 Oct 2008 17:40:24 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m95LeNuW007003; Sun, 5 Oct 2008 17:40:23 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: "Steven M. Bellovin" In-Reply-To: <20081003121530.5f686a5f@cs.columbia.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> <20081003121530.5f686a5f@cs.columbia.edu> Date: Fri, 03 Oct 2008 10:38:23 -0700 Message-Id: <1223055503.27692.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.23.91 Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org, Joe Touch Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 2008-10-03 at 12:15 -0400, Steven M. Bellovin wrote: > On Fri, 03 Oct 2008 07:32:44 -0700 > Bill Sommerfeld wrote: > > It is IMHO not necessary to specify what a label-unaware system should > > do with a labeled packet -- if they get one at all, it's a serious > > error on the part of the sender. > > > Actually, 793 disagrees: > > The security paramaters may be used even in a non-secure environment > (the values would indicate unclassified data), thus hosts in > non-secure environments must be prepared to receive the security > parameters, though they need not send them. > > The question is how realistic that statement is. As you probably would have guessed, I think it's entirely unrealistic. - Bill _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Oct 5 14:59:53 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14B73A69A8; Sun, 5 Oct 2008 14:59:53 -0700 (PDT) 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 3AE3E3A6934; Sun, 5 Oct 2008 14:59:52 -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=[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 LoxsNVol2-Vv; Sun, 5 Oct 2008 14:59:51 -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 589463A68E5; Sun, 5 Oct 2008 14:59:49 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m95M0D57016710; Sun, 5 Oct 2008 22:00:13 GMT Received: from localhost.east.sun.com (vroom.SFBay.Sun.COM [10.7.251.192]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m95M06EK029137; Sun, 5 Oct 2008 18:00:07 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m93EWx8s022753; Fri, 3 Oct 2008 07:32:59 -0700 (PDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m93EWmga022748; Fri, 3 Oct 2008 07:32:48 -0700 (PDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Joe Touch In-Reply-To: <48E624F5.7000203@isi.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> Date: Fri, 03 Oct 2008 07:32:44 -0700 Message-Id: <1223044364.21925.20.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.23.91 Cc: TSV Area , draft-stjohns-sipso-05@tools.ietf.org, saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 2008-10-03 at 06:58 -0700, Joe Touch wrote: > There appears to be at least one change that might be required by all > Internet hosts; current behavior upon receipt of an IP packet at a > security level not supported is to send a TCP RST. This document > indicates that such hosts MUST silently drop such packets. In a securely-configured MLS environment, systems not running an MLS operating system will never receive a packet with an MLS label -- if they did, that inherently means that an MLS system somewhere is misconfigured and information is flowing in violation of the MLS policy. It is IMHO not necessary to specify what a label-unaware system should do with a labeled packet -- if they get one at all, it's a serious error on the part of the sender. > > 2) MLS operating systems have different requirements: > > In turn, this specification *only* applies to Multi-Level > > Secure (MLS) operating systems that choose to implement > > this particular IPv6 labelling specification. The draft > > is very clear about this. > > The draft does not appear to indicate how an MLS system would interact > with legacy systems that are not updated. are you asking about labeled or unlabeled interoperability? the MLS systems I'm familiar with are configured with policy indicating the clearances of other hosts. That policy can indicate whether or not packets to the other system should contain an explicit MLS label. non-MLS systems will typically never see a label. > > 3) The MLS-specific proposal is accepted by long-term > > members of the Transport community: > > Please see Dave Borman's note to the IETF discuss > > list from yesterday. Dave has about as much TCP > > experience as anyone. > > I consider it very incomplete with regard to the impact of the changes > proposed on the architecture of MLS endpoints. I have a modest amount of MLS implementation experience. I believe the spec is complete enough to publish in its current form. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Oct 5 23:12:44 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CAE328C128; Sun, 5 Oct 2008 23:12:44 -0700 (PDT) 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 9AA013A6814 for ; Fri, 3 Oct 2008 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ebY8tlRnoVhY for ; Fri, 3 Oct 2008 08:45:52 -0700 (PDT) Received: from sb4.jpmchase.com (sb4.jpmchase.com [170.148.48.190]) by core3.amsl.com (Postfix) with ESMTP id B767A3A6765 for ; Fri, 3 Oct 2008 08:45:49 -0700 (PDT) Received: from si3.svr.bankone.net (internalhost.FCNBD.com [155.180.56.115] (may be forged)) by sb4.jpmchase.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id m93FkJRQ012813 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 3 Oct 2008 11:46:19 -0400 Received: from bankone.net (imf2.svr.bankone.net [155.180.232.176]) by si3.svr.bankone.net (Switch-3.1.8/Switch-3.1.7) with ESMTP id m93Fk35i016937 for ; Fri, 3 Oct 2008 11:46:03 -0400 Received: from ([169.81.212.251]) by imf2.bankone.net with ESMTP id KP-BRAVB.94078419; Fri, 03 Oct 2008 11:45:39 -0400 Received: from swilntb886.jpmchase.net ([169.81.213.62]) by swilntb870.jpmchase.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 11:44:46 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Oct 2008 11:44:45 -0400 Message-ID: In-Reply-To: <48E6367D.8050905@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] draft-stjohns-sipso-05 & transport protocols Thread-Index: AcklapzGQNKzEObfSLua8aAQNaWSKgAAliew From: To: , X-OriginalArrivalTime: 03 Oct 2008 15:44:46.0236 (UTC) FILETIME=[F61AEDC0:01C9256E] X-Mailman-Approved-At: Sun, 05 Oct 2008 23:12:43 -0700 Cc: saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org You can't wholly eliminate leaks this way; both sender and receiver "should" try to block them (a feature for networked mls systems a long time now; this was present in msx-11 (on DECUS 11-SP-6, 1979) and probably others. If receiver goes into promiscuous mode on a non MLS system they'll get these, but at least the amount of such cruft in most cases will be reduced. Sender "should" ensure this cannot happen, but you get what you get... -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org]On Behalf Of Joe Touch Sent: Friday, October 03, 2008 11:13 AM To: Bill Sommerfeld Cc: draft-stjohns-sipso-05@tools.ietf.org; TSV Area; saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Sommerfeld wrote: > On Fri, 2008-10-03 at 06:58 -0700, Joe Touch wrote: > >> There appears to be at least one change that might be required by all >> Internet hosts; current behavior upon receipt of an IP packet at a >> security level not supported is to send a TCP RST. This document >> indicates that such hosts MUST silently drop such packets. > > In a securely-configured MLS environment, systems not running an MLS > operating system will never receive a packet with an MLS label -- if > they did, that inherently means that an MLS system somewhere is > misconfigured and information is flowing in violation of the MLS policy. > > It is IMHO not necessary to specify what a label-unaware system should > do with a labeled packet -- if they get one at all, it's a serious error > on the part of the sender. Serious errors occur all the time. The expected behavior of the MLS in interacting with a non-MLS endpoint should be explained *when* that happens. >>> 2) MLS operating systems have different requirements: >>> In turn, this specification *only* applies to Multi-Level >>> Secure (MLS) operating systems that choose to implement >>> this particular IPv6 labelling specification. The draft >>> is very clear about this. >> The draft does not appear to indicate how an MLS system would interact >> with legacy systems that are not updated. > > are you asking about labeled or unlabeled interoperability? Both, since you brought it up, but I was originally thinking of unlabeled. > the MLS systems I'm familiar with are configured with policy indicating > the clearances of other hosts. That policy can indicate whether or not > packets to the other system should contain an explicit MLS label. > > non-MLS systems will typically never see a label. Agreed, but (as above), this still needs to be explicit in this doc IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmNnwACgkQE5f5cImnZrvxMwCdGlmhiMSi3r3bPo0B6abiIl3X gKsAoORmH5FjuWI8MwC7L4G9hhGdoHFj =bx1E -----END PGP SIGNATURE----- _______________________________________________ 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 saag-bounces@ietf.org Sun Oct 5 23:47:06 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3BA828C18A; Sun, 5 Oct 2008 23:47:06 -0700 (PDT) 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 441C428C187 for ; Sun, 5 Oct 2008 23:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 KMsCfLnxzYL0 for ; Sun, 5 Oct 2008 23:47:04 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 45AC428C18A for ; Sun, 5 Oct 2008 23:47:04 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8B000K41J2EU@szxga01-in.huawei.com> for saag@ietf.org; Mon, 06 Oct 2008 14:47:26 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8B00FS51J2K5@szxga01-in.huawei.com> for saag@ietf.org; Mon, 06 Oct 2008 14:47:26 +0800 (CST) Received: from s00102542 ([10.111.12.200]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8B007AU1IYFQ@szxml04-in.huawei.com> for saag@ietf.org; Mon, 06 Oct 2008 14:47:26 +0800 (CST) Date: Mon, 06 Oct 2008 14:47:23 +0800 From: Sean Shen In-reply-to: <1222812372.31539.40.camel@moss-terrapins.epoch.ncsc.mil> To: "'David P. Quigley'" , paul.moore@hp.com, latten@austin.ibm.com, Kurt.Zeilenga@Isode.com, saag@ietf.org, rja@extremenetworks.com, Nicolas.Williams@sun.com, Jarrett.Lu@sun.com Message-id: <011101c9277f$638302f0$c80c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AckjS44U7ANexpkNQtqZjr6G++xBHQEM46Tg Subject: Re: [saag] Call for Participation: IETF 73 MAC Labeling Bar BOF 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org hi, Dave, I am not clear about the prospective topics of the bar bof. Can you point me to the 3 draft you mentioned? Thanks Sean >-----Original Message----- >From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On >Behalf Of David P. Quigley >Sent: Wednesday, October 01, 2008 6:06 AM >To: paul.moore@hp.com; latten@austin.ibm.com; >Kurt.Zeilenga@Isode.com; saag@ietf.org; >rja@extremenetworks.com; Nicolas.Williams@sun.com; Jarrett.Lu@sun.com >Subject: [saag] Call for Participation: IETF 73 MAC Labeling Bar BOF > >Hello, > >I am organizing a Bar BOF to discuss the use of security >labels in IETF protocols. Recently there have been at least >three drafts introduced to the IETF which deal with security >labels. While there may be other drafts in the work that deal >with this topic, from the three I've seen there is at least >one issue where myself and others believe we need to reach a >consensus. > >According to the IETF 73 cutoff dates list we won't know the >final agenda for the event until October 27th. Once this date >rolls around I will post a list of suggested dates and times >for the BOF to take place. I also need to figure out where in >the hotel to host the BOF. As the name suggests we can hold it >in the hotel's bar, however another suggestion has been to get >a room at a restaurant and hold the meeting over dinner. >Depending on the interest in this BOF neither of these options >may accommodate the number of people interested. In that case >I'll have to see if I can find a more suitable place to hold the BOF. >Hopefully I will have this information to you before we arrive >at IETF 73 but if I don't I'll make sure I inform everyone of >where I will post the information. > >As of right now I have four people interested in the BOF and I >hope to have more as time passes. I would like to be able to >create a mailing list for the BOF but unfortunately I am not >able to do that where I am. If someone else would like to host >the mailing list (Not to be taken as a solicitation by the US >Govt) that would be great. For now if you are interested in >the BOF feel free to email me so I have an idea of the general >interest. > >The current agenda only has one item on it and that is the >specification of a DOI. In the recent weeks I've read three >drafts that have three different specifications of Domains of >Interpretation (DOIs). While this is the only thing I have at >the moment if you have other suggestions for topics or drafts >you would like to discuss please bring them to my attention so >I can make sure to add them to the agenda. > >Dave Quigley > >_______________________________________________ >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 saag-bounces@ietf.org Mon Oct 6 09:52:30 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1997A3A6A48; Mon, 6 Oct 2008 09:52:30 -0700 (PDT) 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 CFC053A68F8; Mon, 6 Oct 2008 09:52:28 -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=[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 45WubfmcVAqa; Mon, 6 Oct 2008 09:52:25 -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 B2CFF3A67DD; Mon, 6 Oct 2008 09:52:24 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m96GqYi8028497; Mon, 6 Oct 2008 16:52:34 GMT Received: from localhost.east.sun.com (vroom.SFBay.Sun.COM [10.7.251.192]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m96GqWjg015473; Mon, 6 Oct 2008 12:52:33 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m95LeNi9007006; Sun, 5 Oct 2008 17:40:24 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m95LeNuW007003; Sun, 5 Oct 2008 17:40:23 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: "Steven M. Bellovin" In-Reply-To: <20081003121530.5f686a5f@cs.columbia.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> <20081003121530.5f686a5f@cs.columbia.edu> Date: Fri, 03 Oct 2008 10:38:23 -0700 Message-Id: <1223055503.27692.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.23.91 Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org, Joe Touch Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 2008-10-03 at 12:15 -0400, Steven M. Bellovin wrote: > On Fri, 03 Oct 2008 07:32:44 -0700 > Bill Sommerfeld wrote: > > It is IMHO not necessary to specify what a label-unaware system should > > do with a labeled packet -- if they get one at all, it's a serious > > error on the part of the sender. > > > Actually, 793 disagrees: > > The security paramaters may be used even in a non-secure environment > (the values would indicate unclassified data), thus hosts in > non-secure environments must be prepared to receive the security > parameters, though they need not send them. > > The question is how realistic that statement is. As you probably would have guessed, I think it's entirely unrealistic. - Bill _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Oct 6 10:46:11 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4ED28C116; Mon, 6 Oct 2008 10:46:11 -0700 (PDT) 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 76DEF3A6ADA; Mon, 6 Oct 2008 10:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[AWL=-0.236, 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 eI94U4HRk3mZ; Mon, 6 Oct 2008 10:46:06 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 91BDB3A6ADB; Mon, 6 Oct 2008 10:45:48 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1Kmu9N-00044L-CE; Mon, 06 Oct 2008 13:45:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1223044364.21925.20.camel@localhost> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> Date: Mon, 6 Oct 2008 12:53:04 -0400 To: Bill Sommerfeld From: Stephen Kent Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org, Joe Touch Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 7:32 AM -0700 10/3/08, Bill Sommerfeld wrote: >On Fri, 2008-10-03 at 06:58 -0700, Joe Touch wrote: > >> There appears to be at least one change that might be required by all >> Internet hosts; current behavior upon receipt of an IP packet at a >> security level not supported is to send a TCP RST. This document >> indicates that such hosts MUST silently drop such packets. > >In a securely-configured MLS environment, systems not running an MLS >operating system will never receive a packet with an MLS label -- if >they did, that inherently means that an MLS system somewhere is >misconfigured and information is flowing in violation of the MLS policy. I'm not sure I agree with this statement, Bill. A single-level or dedicated mode host MIGHT receive such packets IF an MLS hosts is configured to always send labelled packets. Such hosts MIGHT be configured to accept and emit packets with a fixed secruity level, as part of an overall, local config policy. Such systems, while not MLS, would not be label-unaware. I am familiar with plans that called for such behavior in the RFC 1108 context. Note that a BLACKER E2E crypto unit configured to support a single-level host would behave this way, but since the BLACKER was MLS (even though a host behind it might not be), that example does not exactly fit the description above. Steve _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Oct 6 11:02:02 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3993A6B18; Mon, 6 Oct 2008 11:02:02 -0700 (PDT) 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 350CE3A6B17 for ; Mon, 6 Oct 2008 11:02:01 -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=-2.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 eUncN6VJHXMV for ; Mon, 6 Oct 2008 11:01:57 -0700 (PDT) Received: from zombie2.ncsc.mil (zombie2.ncsc.mil [144.51.88.133]) by core3.amsl.com (Postfix) with ESMTP id 7BF803A679F for ; Mon, 6 Oct 2008 11:01:57 -0700 (PDT) Received: from facesaver.epoch.ncsc.mil (jazzdrum.ncsc.mil [144.51.5.7]) by zombie2.ncsc.mil (8.12.10/8.12.10) with ESMTP id m96HxUcv011867; Mon, 6 Oct 2008 17:59:30 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by facesaver.epoch.ncsc.mil (8.13.1/8.13.1) with ESMTP id m96I0Yjq027687; Mon, 6 Oct 2008 14:00:35 -0400 From: "David P. Quigley" To: Sean Shen In-Reply-To: <011101c9277f$638302f0$c80c6f0a@china.huawei.com> References: <011101c9277f$638302f0$c80c6f0a@china.huawei.com> Content-Type: multipart/mixed; boundary="=-xpVbHRECGS236h4ogPyT" Date: Mon, 06 Oct 2008 13:41:31 -0400 Message-Id: <1223314891.31539.103.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Cc: Nicolas.Williams@sun.com, Kurt.Zeilenga@Isode.com, saag@ietf.org, latten@austin.ibm.com, Jarrett.Lu@sun.com Subject: Re: [saag] Call for Participation: IETF 73 MAC Labeling Bar BOF 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: , Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --=-xpVbHRECGS236h4ogPyT Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, Sorry for taking so long to respond to this but I was out sick the better part of last week. The three documents are listed below and one of them is attached to the email since it was an RFC posting to the SELinux mailing list. That attachment is by Joy Latten of IBM and pertains to labeled IPsec. MAC Security Label Requirements for NFSv4 http://tools.ietf.org/id/draft-quigley-nfsv4-sec-label-requirements-01.txt Common Architecture Label IPv6 Security Option (CALIPSO) http://tools.ietf.org/id/draft-stjohns-sipso-05.txt Two attached Documents by Joy Latten for Labeled IPSec Dave On Mon, 2008-10-06 at 14:47 +0800, Sean Shen wrote: > hi, Dave, > I am not clear about the prospective topics of the bar bof. Can you point me > to the 3 draft you mentioned? > Thanks > > Sean > > >-----Original Message----- > >From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On > >Behalf Of David P. Quigley > >Sent: Wednesday, October 01, 2008 6:06 AM > >To: paul.moore@hp.com; latten@austin.ibm.com; > >Kurt.Zeilenga@Isode.com; saag@ietf.org; > >rja@extremenetworks.com; Nicolas.Williams@sun.com; Jarrett.Lu@sun.com > >Subject: [saag] Call for Participation: IETF 73 MAC Labeling Bar BOF > > > >Hello, > > > >I am organizing a Bar BOF to discuss the use of security > >labels in IETF protocols. Recently there have been at least > >three drafts introduced to the IETF which deal with security > >labels. While there may be other drafts in the work that deal > >with this topic, from the three I've seen there is at least > >one issue where myself and others believe we need to reach a > >consensus. > > > >According to the IETF 73 cutoff dates list we won't know the > >final agenda for the event until October 27th. Once this date > >rolls around I will post a list of suggested dates and times > >for the BOF to take place. I also need to figure out where in > >the hotel to host the BOF. As the name suggests we can hold it > >in the hotel's bar, however another suggestion has been to get > >a room at a restaurant and hold the meeting over dinner. > >Depending on the interest in this BOF neither of these options > >may accommodate the number of people interested. In that case > >I'll have to see if I can find a more suitable place to hold the BOF. > >Hopefully I will have this information to you before we arrive > >at IETF 73 but if I don't I'll make sure I inform everyone of > >where I will post the information. > > > >As of right now I have four people interested in the BOF and I > >hope to have more as time passes. I would like to be able to > >create a mailing list for the BOF but unfortunately I am not > >able to do that where I am. If someone else would like to host > >the mailing list (Not to be taken as a solicitation by the US > >Govt) that would be great. For now if you are interested in > >the BOF feel free to email me so I have an idea of the general > >interest. > > > >The current agenda only has one item on it and that is the > >specification of a DOI. In the recent weeks I've read three > >drafts that have three different specifications of Domains of > >Interpretation (DOIs). While this is the only thing I have at > >the moment if you have other suggestions for topics or drafts > >you would like to discuss please bring them to my attention so > >I can make sure to add them to the agenda. > > > >Dave Quigley > > > >_______________________________________________ > >saag mailing list > >saag@ietf.org > >https://www.ietf.org/mailman/listinfo/saag > > > --=-xpVbHRECGS236h4ogPyT Content-Disposition: attachment; filename=draft-jml-ipsec-ikev1-security-label-00.txt Content-Type: text/plain; name=draft-jml-ipsec-ikev1-security-label-00.txt; charset=utf-8 Content-Transfer-Encoding: 7bit Network Working Group J. Latten Internet-Draft G. Wilson Intended Status: Standards Track S. Hallyn Expires: ? IBM T. Jaeger Penn State June 2008 Security Label Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) draft-jml-ipsec-ikev1-security-label-00 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December, 2008. Copyright Notice Copyright (C) The IETF Trust (2008) Abstract This document describes the need for and the use of a security label within IPsec. It describes the extension to the Internet IP Security Latten, et al. Expires ? [Page 1] Internet-Draft IKEv1SecurityLabel June 2008 Domain of Interpretation (IPsec DOI) [RFC2407] for the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. This extension supports the negotiation of the security label for a particular IP Authentication Header (AH) [RFC4302] or IP Encapsulating Security Payload (ESP) [RFC4303] security association. 1. Introduction Traditionally, security context referred to the security level and category used by Multilevel Security (MLS). This document will refer to the security level and category as the security classification. Current security mechanisms, such as SELinux, use the security classification and additional security attributes to form their security context. For example, a type for type enforcement. Techniques such as IP Security Options (IPSO) allow IP datagrams to be labeled with an MLS security classification [RFC1108]. This ensured the same security applied to local objects and resources was utilized when communicating over the network with homogenous systems. However, these techniques cannot pass along the additional security attributes used in current security mechanisms. The ISAKMP specification defines a Situation field in the Security Association payload [RFC2408]. The IPsec DOI describes the use of this field to communicate sensitivity and integrity classification information between initiator and responder when negotiating a security association [RFC2407]. However, it does not provide for additional security attributes that may be required by the security mechanism being deployed in the environment. This document describes the additions to the IPsec DOI for ISAKMP that are needed to support communication of additional security attributes between two hosts, in particular a security label. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Latten, et al. Expires ? [Page 2] Internet-Draft IKEv1SecurityLabel June 2008 3. IPsec Security Association Attribute The following SA attribute definition is used in Phase II of an Internet Key Exchange Protocol (IKE) negotiation that includes a security label. The attribute type is Variable-Length (V). Encoding of attributes is defined in the base ISAKMP specification [RFC2408]. Attribute Type class value type ------------------------------------------------------ Security Label ? V Class Values Security Label Specifies that the security association is being negotiated in an environment that requires labeled security. This field will contain the security label. The security label has the following format. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | doi | algorithm | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | security label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Security Label format - doi (1 octet) - The first octet contains the security label's domain of interpretation. The domain of interpretation can be viewed as a group of systems that agree on the meaning of particular values within the security label of a security mechanism. The value of 1 is reserved as the default. Reserved 0 Default 1 - algorithm (1 octet) - The second octet contains the security label's algorithm. Latten, et al. Expires ? [Page 3] Internet-Draft IKEv1SecurityLabel June 2008 The security label's algorithm specifies the security mechanism or context in which the label is applicable. For example, the security label is interpreted within the SELinux context. Requests for assignment of additional algorithms should be addressed to the Internet Assigned Numbers Authority (IANA). Reserved 0 SELinux 1 Smack 2 Private Use 120-128 - length (2 octets) - The third and fourth octets contain the string length of the security context. - security label (1 or more octets) - The security label. The actual content will be dependent on the security algorithm that is specified. Within IKE context, this is regarded as an opaque bit string. 3. Attribute Negotiation If an implementation receives an IPsec DOI attribute or attribute value that it does not support, it SHOULD send an ATTRIBUTES-NOT-SUPPORT and the security association negotiation and setup MUST be aborted. 4. Security Considerations This document describes an extension to IKE [RFC2409] and ISAKMP [RFC2408] protocols. The use of the described security label should not change the basic security features of the two. The IPsec DOI describes a Situation field whose values can be SIT_SECRECY and/or SIT_INTEGRITY. When SIT_SECRECY is used, it indicates an environment requiring labeled secrecy and is followed with sensitivity label. When SIT_INTEGITY is used, it indicates an environment requiring labeled integrity and is followed with integrity information. SIT_SECRECY and SIT_INTEGRITY themselves indicate the use of a security label and therefore the security attribute described in this document MUST NOT be used in conjunction with either. The new security attribute extends the existing security mechanism to allow for additional interpretations of a security label and not just those defined by SIT_SECRECY and SIT INTEGRITY. It is possible that the sensitivity level and/or integrity level are Latten, et al. Expires ? [Page 4] Internet-Draft IKEv1SecurityLabel June 2008 included in the security label defined by the security algorithm using the new security attribute. 5. IANA Considerations This document contains two new "magic numbers" which are allocated and maintained by IANA registry. - The class value for the security label attribute. class value type ----------------------------------------- Security Label ? V Only one value assigned by IANA is required. - The value for the security algorithm. SELinux 1(?) Smack 2(?) Additional values may be assigned by IANA for the security mechanisms requiring IKE to communicate its security label. Acknowledgements The authors would like to thank Stephen Smalley, James Morris and the SELinux community for their work on labeled ipsec. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. Latten, et al. Expires ? [Page 5] Internet-Draft IKEv1SecurityLabel June 2008 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. Informative references [RFC1108] Kent, S., "U.S. DoD Security Options for the Internet Protocol, RFC 1108, November 1991. Authors' Addresses Joy Latten IBM email: latten@austin.ibm.com George Wilson IBM email: gcwilson@us.ibm.com Serge Hallyn IBM email: serue@us.ibm.com Trent Jaeger Penn State email: tjaeger@cse.psu.edu Latten, et al. Expires ? [Page 6] Internet-Draft IKEv1SecurityLabel June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. --=-xpVbHRECGS236h4ogPyT Content-Disposition: attachment; filename=draft-jml-ipsec-ikev2-security-label-00.txt Content-Type: text/plain; name=draft-jml-ipsec-ikev2-security-label-00.txt; charset=utf-8 Content-Transfer-Encoding: 7bit Network Working Group J. Latten Internet-Draft G. Wilson Intended Status: Standards Track S. Hallyn Expires: ? IBM T. Jaeger Penn State July 2008 Security Label Addendum to IPsec draft-jml-ipsec-ikev2-security-label-00 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December, 2008. Copyright Notice Copyright (C) The IETF Trust (2008) Abstract This document describes the high-level requirements needed within IPsec to support Mandatory Access Control (MAC) on network communications. It describes the extensions to the Security Architecture for the Internet Protocol [RFC4301] and the Internet Key Exchange Protocol Version 2 [RFC4306]. It also describes the Latten, et al. Expires ? [Page 1] Internet-Draft IKEv2SecurityLabel June 2008 negotiation of the security label for a particular Authentication Header (AH) [RFC4302] and/or Encapsulating Security Payload (ESP) [RFC4303] security association. 1. Introduction In computer security, Mandatory Access Control usually refers to a system in which all subjects and objects are labeled with a security context. The security context is comprised of a set of security attributes. The security contexts along with a system authorization policy determine access. Rules within the system authorization policy determine whether the access will be granted based on the security attributes of the subject and object. Traditionally, MAC implied Multilevel Security (MLS) systems. MLS utilizes a security context consisting of a sensitivity or security level and category. This document will refer to the security level and category as the security classiffication. In MLS, the use of a security classification allowed segregation of information thus facilitating data confidentiality. MAC systems have become more mainstream and is no longer just associated with MLS. Within a strictly hierarchical system such as MLS, often there are tasks that need to be exempt from the MLS policy, thus leaving them exposed. However, methods such as Type Enforcement (TE) are not hierarchical and allow precise rules to be written about access using security attributes [MayMacCap]. TE can be used to control access these "exempt" tasks. A MAC system can employ both MLS and TE to control access. Such systems require additional security attributes besides the security classification used by MLS. For example, a domain type attribute may be used to control access in TE [MayMacCap]. These MAC systems concentrate on securing local objects and resources but have no way of applying their security contexts to network communications to ensure the same security when communicating with homogenous systems. Techniques such as IP Security Options (IPSO) allow IP datagrams to be labeled with a MLS security classification [RFC1108]. However, they do not accomodate additional security attributes such as the type in TE. MAC implementations requiring additional security attributes, such as SELinux, can use IPsec mechanisms to control access [LevIPsecMAC]. This document will describe how IPsec mechanisms can support MAC networking. It will also describe the additions to IKEv2 to support communication of a security context during negotiations to Latten, et al. Expires ? [Page 2] Internet-Draft IKEv2SecurityLabel June 2008 establish an AH and ESP security association. Within this document, security label and security context refer to the same thing. And MAC networking and labeled networking are used interchangeably. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Labeled Networking Within a MAC environment, the underlying security mechanism applies a security context to all the subjects and objects on the local system. The security context along with a MAC authorization policy determines whether a subject may access an object. In labeled networking, a security context is applied to data exported over the network. The MAC system can then use labeled networking to make informed access decisions. Systems wishing to communicate with each other must deploy the same MAC authorization policy and security context for consistency. IPsec mechanisms can support labeled networking whether implicit or explicit labels are being used. Explicit labeling refers to transmitting the security context in the IP datagram, such as in IPSO. When explicit labeling is used the encryption and authentication services provided in IPsec can be used to authenticate the bindings between the security label in the IP header and payload and provide confidentiality [RFC2401]. In an implicit labeling scheme, the security context is not transmitted as part of the IP datagram. IPsec provides implicit labeling in that the security context is part of the IPsec Security Association and not transmitted with each packet. 3.1 Relationship Between a Security Association and Security Label In MAC networking, the traffic between two systems may require several different security contexts. For example, ftp and a mail program may each label their data with a different security context. Recall that SAs exist in pairs, one for inbound and one for outbound. Each instance of a security label will require an SA pair. Thus traffic between two systems may have several SA pairs with identical selectors except for the security context. If using a combination of Latten, et al. Expires ? [Page 3] Internet-Draft IKEv2SecurityLabel June 2008 ESP and AH, then there will be an ESP SA pair and an AH SA pair per instance of a security label. 3.2 Security Context Selector [RFC4301] describes the Security Policy Database (SPD), and the Security Association Database (SAD) and corresponding selectors. MAC networking introduces an additional selector, the Security Context selector. This selector is only required when MAC networking is deployed. - Security Context: MAC implementation's security context. The security context can be an IPSO/CIPSO label when IPsec is used to support explicit labels. Recall, in MAC networking, multiple SAs may exist between two systems differing only in their security labels. The Security Context selector ensures that the appropriate SA pair is used to secure a particular communication. The Security Context selector within the SPD allows the system administrator to specify which traffic streams will be authorized to communicate within the system's MAC policy. It also specifies which traffic streams will have labeled communications and which will not. 3.3 Security Context Selector and PFP [RFC4301] introduced and described Populate From Packet (PFP) flags. When creating an SA, the PFP flag determines whether to instantiate the corresponding selector in the new SA with information from the packet that triggered the creation or from information in the corresponding SPD entry. In MAC implementations, the security context that will be associated with the new SA MUST NOT be the SPD entry's security context. The security contexts in the SPD entry and in the SA entry are to label two different objects respectively. The security context in the SPD entry controls access to the entry itself and it's IPsec configuration information. Thus the SPD entry itself is considered an object. The SA's security context provides security attributes for the packet which can also indicate the security attributes of the sender or process. Keeping these separate allows a MAC implementation to control which packets may use a particular IPsec configuration. Therefore, when using IPsec to provide implicit labels, the PFP flag must not be used to determine where to get the security context for the new SA. Latten, et al. Expires ? [Page 4] Internet-Draft IKEv2SecurityLabel June 2008 3.4 Outbound Processing for MAC Networking When consulting the SPD for an outbound policy, the data's security label is used to determine if it is authorized to access the particular SPD entry and use its configuration information for sending. This adds the additional check in that the outbound packet will not generate an SA pair that the policy entry does not allow. So for example, in an MLS implementation, a high secrecy process cannot generate an SA allowing it to send data to a low secrecy process. Similarly, when consulting the SAD to find an outbound SA, the the data's security context is used to select the appropriate SA to send on. In the case that a suitable outbound policy is found, but there isn't an SA, the message sent to the key management system to create an SA MUST contain the security label associated with the data. This allows for the key manager to create an SA pair with the correct security label for the data to be transmitted. A MAC implementation MAY label it's interface and/or configured IP address. If so, before forwarding the packet out to its destination, a check should be made that the outbound packet is authorized to send out on the interface and/or configured ip address [RFC2401]. 3.4 Inbound Processing for MAC Networking The use of the SPI to map IPsec protected packets to an SA ensures we select the correct SA to process the inbound packet. The MAC implementation MUST retain the binding between the data received in the IPsec protected packet and the security label in the SA used to process the packet. This is required so that suitable MAC policy decisions can be made when delivering the data to an application or when fowarding. The means for maintaining this binding are implementation specific. [RFC2401] A MAC implementation MAY label it's interface or configured IP address. If so, the MAC implementation SHOULD check the inbound packet's security label (as defined by the SA used to process the packet) with the security label of the interface or configured IP address before forwarding to upper-layer protocol or to destination [RFC2401]. 3.5 MAC Processing for Security Gateways A security gateway enforcing MAC and using labeled SAs MUST follow Latten, et al. Expires ? [Page 5] Internet-Draft IKEv2SecurityLabel June 2008 the inbound and outbound processing mentioned above as well as some additional processing particular to the intermediate protection of packets in a MAC environment [RFC2401]. A security gateway enforcing MAC MUST create and use appropriate SAs to protect packets that it forwards for systems behind it. [RFC2401] The systems behind the security gateway may or may not be using MAC. The gateway SHOULD utilize various attributes of the traffic and/or existing labels to determine the security labels for the SAs to be created and applied. Similarly, such a gateway SHOULD accept and process inbound AH and/or ESP packets and forward appropriately, utilizing various attributes of the traffic and/or existing labels [RFC2401]. 4. Security Context Transform When the initiator requests a new SA to be created, the security context is communicated in the information required for the new IPsec SA. Security contexts are not communicated for IKE_SAs, only IPsec SAs. The following transform definition is used to communicate a security context when creating the CHILD_SA in the IKE_AUTH exchange or when creating or rekeying an IPsec SA in the CREATE_CHILD_SA exchange. The transform type value is: Description Transform Type Used In ................................................. Security Context (?)6 ESP and AH When using IPsec's implicit labelin, the existence of a security context for the SPD entry indicates all SAs created by this entry MUST be labeled. If an SPD entry does not have a security context, then resulting SAs will not have a security context. Within MAC it may be desireable that some network communications not be labeled and just protected by IPsec. For example, a security gateway enforcing MAC but the systems behind it do not. These SPD entries would not have a security context. However, when the security gateway talks to another security gateway, it may want to use implicit labeling. Therefore, the use of a security context with the ESP and AH protocols when MAC is enforced is optional. Only one transform of type (?)6 is allowed per protocol. In other words, you cannot communicate two different security contexts within a single SA payload being negotiated. Latten, et al. Expires ? [Page 6] Internet-Draft IKEv2SecurityLabel June 2008 For Transform Type (?)6 (Security Context), the defined Transform IDs are: Security Mechanism Number ........................................... Reserved 0 SELinux (?)1 Smack (?)2 Reserved to IANA (?)3 - 1023 Private Use 1024 - 65535 The Transform Attribute Type: Attribute Type Value Attribute Format ....................................................... Security Context (?)18 TLV The attribute format is Type/Length/Value allowing for a variable length security context. The security context has the following format. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | doi | security context (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Security Context Format - doi (1 octet) - The first octet contains the security label's domain of interpretation. The domain of interpretation can be viewed as a group of systems that agree on the meaning of particular values within the security label of a security mechanism. Reserved 0 Default (?)1 Private Use (?)2 - 255 - security context (variable length number of octets) The actual content will be dependent on the security mechanism that is specified. Within IKE context, this is regarded as an opaque bit string. Latten, et al. Expires ? [Page 7] Internet-Draft IKEv2SecurityLabel June 2008 4.1 Attribute Negotiation The description of attribute negotiation in [RFC4306] is applicable also when using security contexts. In addition, only one security context transform (Type 6) is allowed per protocol. And if the initiator sends multiple proposals when negotiating an SA, each proposal MUST contain the same transform type and security context. In other words, a single SA negotiation should contain only one security context. 4.3 CREATE_CHILD_SA Exchange [RFC4306] describes the NO_ADDITIONAL_SAS notification. This notification is sent by a responder who is unwilling to accept additional SAs on an IKE_SA or a minimal IPsec implementation. Within MAC, the data transmitted between two systems may have different security contexts. For example, ftp and telnet data may each have their own security contexts. Each instance of a security context requires an SA pair to support context granularity. There may be multiple SAs with same selectors except for the security context selector. A responder should be willing to accept more than one SA on an IKE_SA in MAC networking. 4. Security Considerations Some IPsec implementations may dynamically update the SPD. If the responder does not have an SPD entry, the information within the SA payload is used to generate an SPD entry. MAC networking may impose limitations on IPsec implementations that dynamically update the SPD. The security contexts associated with an SPD entry and an SA are for different purposes as described already in this document. Therefore, the security context in the SA should not be used as the security context for the SPD entry. IPsec implementations that generate SPD entries during SA negotiation and wish to enforce labeled networking will require a mechanism for system administrators to specify the security context to be used for these SPD entries. Latten, et al. Expires ? [Page 8] Internet-Draft IKEv2SecurityLabel June 2008 5. IANA Considerations This document contains several new numbers which are allocated and maintained by the IANA registry. - The Transform Type value for the security context. Description Transform type ----------------------------------------- Security Context (?)6 - The Transform IDs defined within the Security Context Transform Type. Name Number --------------------------- Reserved 0 SELinux (?)1 Smack (?)2 Reserved to IANA (?)3 - 1023 Private Use 1024 - 65535 Additional values may be assigned by IANA for the security mechanisms requiring IKE to communicate its security label. - The Security Context attribute type. Attribute Type Value Attribute Format ----------------------------------------------------- Security Context (?)18 TLV 6. Acknowledgements The authors would like to thank Stephen Smalley and James Morris for their contributions during the initial design; and the members of the SELinux community who have contributed to the development and improvement of labeled ipsec and this specification. 7. References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. Latten, et al. Expires ? [Page 9] Internet-Draft IKEv2SecurityLabel June 2008 [RFC4306] Kaufman, Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 7.2 Informative References [LevIPsecMAC] Jaeger, T., King, David., Butler, K., Hallyn, S., Latten, J., Zhang, X., "Leveraging IPsec for Mandatory Per-Packet Access Control", 2006 http://www.cse.psu.edu/~tjaeger/papers/securecomm06.pdf [MayMacCap] Mayer, F., Macmillan K., Caplan D., SELinux by Example, Section 1.2.4, Prentice Hall, Upper Saddle River, NJ, 2007 [RFC1108] Kent, S., "U.S. DoD Security Options for the Internet Protocol", RFC 1108, November 1991. [RFC2401] Kent, S., Atkinson, R., Security Architecture for the Internet Protocol, RFC 2401, November 1998. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S. "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. Authors' Addresses Joy Latten IBM email: latten@austin.ibm.com George Wilson IBM email: gcwilson@us.ibm.com Serge Hallyn IBM email: serue@us.ibm.com Trent Jaeger Penn State email: tjaeger@cse.psu.edu Latten, et al. Expires ? [Page 10] Internet-Draft IKEv2SecurityLabel June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Latten, et al. Expires ? [Page 11] --=-xpVbHRECGS236h4ogPyT Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --=-xpVbHRECGS236h4ogPyT-- From saag-bounces@ietf.org Mon Oct 6 18:42:41 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1F83A695E; Mon, 6 Oct 2008 18:42:41 -0700 (PDT) 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 B29263A68C4; Mon, 6 Oct 2008 18:42:40 -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=[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 ojUOkeW5FDGo; Mon, 6 Oct 2008 18:42:39 -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 9B1803A6833; Mon, 6 Oct 2008 18:42:39 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m971hG4d011499; Tue, 7 Oct 2008 01:43:17 GMT Received: from localhost.east.sun.com (vroom.SFBay.Sun.COM [10.7.251.192]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m971hExq054137; Mon, 6 Oct 2008 21:43:15 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m95LfEHn007038; Sun, 5 Oct 2008 17:41:14 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m95LfDYf007034; Sun, 5 Oct 2008 17:41:13 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Joe Touch In-Reply-To: <48E694A1.1080807@isi.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <48E635F3.70308@isi.edu> <2C9D0EA8-A48C-48E7-BF43-9948CE64D395@extremenetworks.com> <48E694A1.1080807@isi.edu> Date: Sun, 05 Oct 2008 17:40:18 -0400 Message-Id: <1223242818.6536.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.23.91 Cc: TSV Area , draft-stjohns-sipso-05@tools.ietf.org, saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 2008-10-03 at 14:54 -0700, Joe Touch wrote: > I.e., if this is really a virtual network, there's a LOT of work left to > be done. All that behavioral description work is entirely independent of the label encoding draft, and there is IMHO no rational reason to delay publication of draft-stjohns-sipso-* (and the allocation of relelvant codepoints by IANA) in order to document minutiae of behavior which are better spelled out in separate drafts documenting the interaction of MLS labeling and specific protocols. - Bill _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Oct 6 18:42:48 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C263A6A89; Mon, 6 Oct 2008 18:42:48 -0700 (PDT) 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 C62043A6A89; Mon, 6 Oct 2008 18:42:46 -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=[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 nuJktsG4zxo1; Mon, 6 Oct 2008 18:42:46 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 989D73A68C4; Mon, 6 Oct 2008 18:42:41 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m971hGi1020025; Tue, 7 Oct 2008 01:43:18 GMT Received: from localhost.east.sun.com (vroom.SFBay.Sun.COM [10.7.251.192]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m971hEgJ054138; Mon, 6 Oct 2008 21:43:15 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m95LeNi9007006; Sun, 5 Oct 2008 17:40:24 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m95LeNuW007003; Sun, 5 Oct 2008 17:40:23 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: "Steven M. Bellovin" In-Reply-To: <20081003121530.5f686a5f@cs.columbia.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <1223044364.21925.20.camel@localhost> <20081003121530.5f686a5f@cs.columbia.edu> Date: Fri, 03 Oct 2008 10:38:23 -0700 Message-Id: <1223055503.27692.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.23.91 Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org, Joe Touch Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 2008-10-03 at 12:15 -0400, Steven M. Bellovin wrote: > On Fri, 03 Oct 2008 07:32:44 -0700 > Bill Sommerfeld wrote: > > It is IMHO not necessary to specify what a label-unaware system should > > do with a labeled packet -- if they get one at all, it's a serious > > error on the part of the sender. > > > Actually, 793 disagrees: > > The security paramaters may be used even in a non-secure environment > (the values would indicate unclassified data), thus hosts in > non-secure environments must be prepared to receive the security > parameters, though they need not send them. > > The question is how realistic that statement is. As you probably would have guessed, I think it's entirely unrealistic. - Bill _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Oct 6 18:52:52 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA60A3A6A86; Mon, 6 Oct 2008 18:52:52 -0700 (PDT) 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 CF6063A6A86; Mon, 6 Oct 2008 18:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 2Xx7mHvG7a7m; Mon, 6 Oct 2008 18:52:51 -0700 (PDT) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id CA6513A682F; Mon, 6 Oct 2008 18:52:50 -0700 (PDT) Received: by machshav.com (Postfix, from userid 512) id 7DA61AF68E; Tue, 7 Oct 2008 01:53:27 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CD0C4AF68A; Tue, 7 Oct 2008 01:53:26 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id BA9348387B0; Mon, 6 Oct 2008 21:53:25 -0400 (EDT) Date: Mon, 6 Oct 2008 21:53:25 -0400 From: "Steven M. Bellovin" To: Bill Sommerfeld Message-ID: <20081006215325.498805b6@cs.columbia.edu> In-Reply-To: <1223242818.6536.11.camel@localhost> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <48E635F3.70308@isi.edu> <2C9D0EA8-A48C-48E7-BF43-9948CE64D395@extremenetworks.com> <48E694A1.1080807@isi.edu> <1223242818.6536.11.camel@localhost> Organization: Columbia University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org, Joe Touch Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Sun, 05 Oct 2008 17:40:18 -0400 Bill Sommerfeld wrote: > On Fri, 2008-10-03 at 14:54 -0700, Joe Touch wrote: > > I.e., if this is really a virtual network, there's a LOT of work > > left to be done. > > All that behavioral description work is entirely independent of the > label encoding draft, and there is IMHO no rational reason to delay > publication of draft-stjohns-sipso-* (and the allocation of relelvant > codepoints by IANA) in order to document minutiae of behavior which > are better spelled out in separate drafts documenting the interaction > of MLS labeling and specific protocols. > I disagree -- I think there have been enough points raised on the clarity of the threat model and some behavioral points that I think more discussion is indicated. Apart from that, it does prescribe behavior at variance with the TCP standard. (As I noted, I think this document is more correct, but it nevertheless contradicts 793.) --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Oct 6 19:12:44 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F2A3A6A89; Mon, 6 Oct 2008 19:12:44 -0700 (PDT) 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 26BDF3A6877; Mon, 6 Oct 2008 19:12:43 -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=[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 85HkcJSmLP3s; Mon, 6 Oct 2008 19:12:42 -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 19EB73A682F; Mon, 6 Oct 2008 19:12:41 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m972DJQ0005340; Tue, 7 Oct 2008 02:13:19 GMT Received: from localhost.east.sun.com (vroom.SFBay.Sun.COM [10.7.251.192]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m972DGaB065363; Mon, 6 Oct 2008 22:13:17 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m93EWx8s022753; Fri, 3 Oct 2008 07:32:59 -0700 (PDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m93EWmga022748; Fri, 3 Oct 2008 07:32:48 -0700 (PDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Joe Touch In-Reply-To: <48E624F5.7000203@isi.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> Date: Fri, 03 Oct 2008 07:32:44 -0700 Message-Id: <1223044364.21925.20.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.23.91 Cc: TSV Area , draft-stjohns-sipso-05@tools.ietf.org, saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 2008-10-03 at 06:58 -0700, Joe Touch wrote: > There appears to be at least one change that might be required by all > Internet hosts; current behavior upon receipt of an IP packet at a > security level not supported is to send a TCP RST. This document > indicates that such hosts MUST silently drop such packets. In a securely-configured MLS environment, systems not running an MLS operating system will never receive a packet with an MLS label -- if they did, that inherently means that an MLS system somewhere is misconfigured and information is flowing in violation of the MLS policy. It is IMHO not necessary to specify what a label-unaware system should do with a labeled packet -- if they get one at all, it's a serious error on the part of the sender. > > 2) MLS operating systems have different requirements: > > In turn, this specification *only* applies to Multi-Level > > Secure (MLS) operating systems that choose to implement > > this particular IPv6 labelling specification. The draft > > is very clear about this. > > The draft does not appear to indicate how an MLS system would interact > with legacy systems that are not updated. are you asking about labeled or unlabeled interoperability? the MLS systems I'm familiar with are configured with policy indicating the clearances of other hosts. That policy can indicate whether or not packets to the other system should contain an explicit MLS label. non-MLS systems will typically never see a label. > > 3) The MLS-specific proposal is accepted by long-term > > members of the Transport community: > > Please see Dave Borman's note to the IETF discuss > > list from yesterday. Dave has about as much TCP > > experience as anyone. > > I consider it very incomplete with regard to the impact of the changes > proposed on the architecture of MLS endpoints. I have a modest amount of MLS implementation experience. I believe the spec is complete enough to publish in its current form. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Oct 6 20:57:42 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C1228C11A; Mon, 6 Oct 2008 20:57:42 -0700 (PDT) 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 B042C3A6939; Mon, 6 Oct 2008 20:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.768 X-Spam-Level: X-Spam-Status: No, score=-2.768 tagged_above=-999 required=5 tests=[AWL=-0.169, 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 VTWpUDfwxXuw; Mon, 6 Oct 2008 20:57:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B43A43A684D; Mon, 6 Oct 2008 20:57:39 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m973vmwT007679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Oct 2008 20:57:50 -0700 (PDT) Message-ID: <48EADE3C.20901@isi.edu> Date: Mon, 06 Oct 2008 20:57:48 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Steven M. Bellovin" References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9@nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD@extremenetworks.com> <48E624F5.7000203@isi.edu> <48E635F3.70308@isi.edu> <2C9D0EA8-A48C-48E7-BF43-9948CE64D395@extremenetworks.com> <48E694A1.1080807@isi.edu> <1223242818.6536.11.camel@localhost> <20081006215325.498805b6@cs.columbia.edu> In-Reply-To: <20081006215325.498805b6@cs.columbia.edu> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-stjohns-sipso-05@tools.ietf.org, TSV Area , saag@ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Bellovin wrote: > On Sun, 05 Oct 2008 17:40:18 -0400 > Bill Sommerfeld wrote: > >> On Fri, 2008-10-03 at 14:54 -0700, Joe Touch wrote: >>> I.e., if this is really a virtual network, there's a LOT of work >>> left to be done. >> All that behavioral description work is entirely independent of the >> label encoding draft, and there is IMHO no rational reason to delay >> publication of draft-stjohns-sipso-* (and the allocation of relelvant >> codepoints by IANA) in order to document minutiae of behavior which >> are better spelled out in separate drafts documenting the interaction >> of MLS labeling and specific protocols. >> > I disagree -- I think there have been enough points raised on the > clarity of the threat model and some behavioral points that I think > more discussion is indicated. Apart from that, it does prescribe > behavior at variance with the TCP standard. (As I noted, I think this > document is more correct, but it nevertheless contradicts 793.) I'm not entirely sure how to proceed. Here's the issue: The goal of draft-stjohns-sipso-* appears to be limited to extending endpoint identifiers primarily for transport protocols - TCP in specific. I.e., it extends transport names (AFAICT). That would make sense if there were security levels associated with ports, as a TCP option. However, the draft is described as an extension of IP, which implies a broader extension of the endpoint namespace (as the document describes). Here's the catch: - - if the doc focuses only on TCP, then: a) the 'virtual network' description needs revision to focus on extending only the impact on transport, notably TCP b) ICMP needs to be addressed, i.e., either ICMP needs to be extended similarly, or the impact on TCP needs to be described. this means either: i) ICMPs would be potentially processed by the security level of the payload, not the header or ii) TCP under MLS should assume ICMPs are black-holed, and thus should disable PMTUD. c) DNS needs to be addressed, notably how SRV records would work in this environment - - if the doc really does need to extend the whole network to understand MLS, then the impact on the whole network needs to be considered - this includes forwarding, routing, multicast, DNS, etc. These are neither minutae nor can these issues be relegated to supplemental documents. If you have a system based on what has been written thus far, you're already making assumptions about the above (some problematic, IMO), and you need to do more than just ignore these elephants. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjq3jsACgkQE5f5cImnZrurAgCeNB8r8brS8XBWXM47lZGoBrun 3+gAnRXob/+YLqdmaveON1S5WtJqEvhM =VxsC -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sat Oct 11 01:22:12 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E83E3A6B11; Sat, 11 Oct 2008 01:22:12 -0700 (PDT) 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 0A0A23A6B11 for ; Sat, 11 Oct 2008 01:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JjFtfIzy5Wpj for ; Sat, 11 Oct 2008 01:22:10 -0700 (PDT) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 1F7293A6874 for ; Sat, 11 Oct 2008 01:22:10 -0700 (PDT) Received: from iCoaster.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 4C4A14F330; Sat, 11 Oct 2008 04:22:56 -0400 (EDT) Received: from localhost ([127.0.0.1]) by iCoaster.does-not-exist.org with esmtp (Exim 4.66) (envelope-from ) id K8KFA7-0001AD-ET; Sat, 11 Oct 2008 10:22:55 +0200 Message-Id: From: Thomas Roessler To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 11 Oct 2008 10:22:55 +0200 X-Mailer: Apple Mail (2.929.2) Cc: =?ISO-8859-1?Q?Dominique_Haza=EBl-Massieux?= Subject: [saag] W3C Workshop on Security Models for Device APIs 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hello, we're seeing an increasing amount of interest in using Web = technologies (i.e., HTML, JavaScript and friends) as a platform for = software development outside the browser sandbox. The mobile sector = seems particularly keen to use this environment as a portable runtime = for all kinds of software. With that interest comes an increasing amount of pressure to add and = standardize all kinds of APIs (from address books and telephone = modules to geolocation [the latter is the topic of a recently-started = working group]), and to come up with a useful model for controlling = access to these APIs -- both in the browser and widget cases. We're workshopping the topic on 10/11 December in London; position = papers (1-5 pages) are due by 30 October. Call for participation: http://www.w3.org/2008/security-ws/ Dominique Haza=EBl-Massieux (copied on this message) is the Team contact = for this workshop; if you have any questions, feel free to contact him = or me. Regards, -- Thomas Roessler, W3C _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Oct 15 09:19:53 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C36428C27A; Wed, 15 Oct 2008 09:19:53 -0700 (PDT) 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 ECF7B28C277 for ; Wed, 15 Oct 2008 09:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 tqjFd8nzxjlu for ; Wed, 15 Oct 2008 09:19:46 -0700 (PDT) Received: from zombie2.ncsc.mil (zombie2.ncsc.mil [144.51.88.133]) by core3.amsl.com (Postfix) with ESMTP id 7099128C268 for ; Wed, 15 Oct 2008 09:19:45 -0700 (PDT) Received: from facesaver.epoch.ncsc.mil (jazzdrum.ncsc.mil [144.51.5.7]) by zombie2.ncsc.mil (8.12.10/8.12.10) with ESMTP id m9FGGeNW013986; Wed, 15 Oct 2008 16:16:40 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by facesaver.epoch.ncsc.mil (8.13.1/8.13.1) with ESMTP id m9FGHsMr006916; Wed, 15 Oct 2008 12:17:54 -0400 From: "David P. Quigley" To: saag@ietf.org Date: Wed, 15 Oct 2008 11:58:32 -0400 Message-Id: <1224086312.18940.53.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Subject: [saag] Mailing List for MAC Labeling Discussions 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hello, Jarrett Lu of Sun was able to set up a mailing list to discuss topics related to the BOF[1]. The main objective at the moment is to clearly define DOIs with respect to MAC Labeling. The traditional view of MAC is purely MLS but from our perspective MAC also contains things like Domain Type Enforcement (DTE). SELinux also includes an MLS field in its security context but there are larger issues to consider. For instance how do you handle negotiation of translations between domains? If a system provides more fine grained protections than the receiver on the other end or vice versa how do you handle this? How do we organize the DOI space? Do we share this space among all protocols or do we create separate spaces for each? In terms of things like Labeled NFS and Labeled IPSec is seems reasonable to maintain the same DOI namespace for both of them. Another issue to consider is should we define a standard internal structure for a security context? Also, some people have mentioned their work with security labels in other spaces within the IETF. If you have anything you would like to discuss with respect to work outside of the realm of DOIs (still MAC related of course) feel free to bring it to the list's attention. [1]http://mail.opensolaris.org/mailman/listinfo/doi-discuss _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Oct 30 04:35:59 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8CE3A694D; Thu, 30 Oct 2008 04:35:59 -0700 (PDT) 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 61A173A6838; Thu, 30 Oct 2008 04:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 EhV8xFxtyaGZ; Thu, 30 Oct 2008 04:35:57 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 02AD23A694D; Thu, 30 Oct 2008 04:35:47 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9UBZK0M016454; Thu, 30 Oct 2008 13:35:44 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 13:35:24 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 13:35:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 13:35:22 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB72020F3B23@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pasi's AD Notes for October 2008 Thread-Index: Ack6g5g9ssk8Wz2hSgmBUmb9QF6RZA== From: To: , X-OriginalArrivalTime: 30 Oct 2008 11:35:24.0644 (UTC) FILETIME=[99746A40:01C93A83] X-Nokia-AV: Clean Subject: [saag] Pasi's AD Notes for October 2008 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi all, 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 - There'll be one security-related BoF in IETF73: OAuth in the applications area. - SecDir mailing list was moved to ietf.org -- remember to use the new address when sending reviews. - Tim and I have been planning the SAAG agenda for Minneapolis. It's the last slot before dinner on Thursday, so we're hoping to keep it quite short, though. - Lars Eggert and I talked with the Outpost24 guys about the TCP DoS vulnerabilities they've found; we're meeting CERT-FI folks next week, and hope to get more details (probably under NDA for now). - I've continued tools development, and tried to sort out the process (from both Nokia and IETF/AMS points of view) of how to actually contribute code and get it running. Not completely successful yet, but making progress. - Big thanks to Paul Hoffman for fixing the spam problem in PKIX mailing list archives (not a single spam after the fix; used to be about 40%). - Working with IANA on fixing the IANA registries for RFC 4909 (needed for draft-jerichow-msec-mikey-genext-oma). - Some discussions about allocating more IPv4/IPv6 addresses for documentation/example use, but nothing conclusive so far. WORKING GROUPS DKIM - draft-ietf-dkim-ssp: in AD Evaluation -- I sent my AD review comments, and I'm waiting for revised ID or reply. - draft-ietf-dkim-overview: in Publication Requested, waiting for me to read it. - Waiting for WG to send list of RFC errata IDs the WG agrees on. - The work items are almost done; some discussions on the list about rechartering or winding down. EMU - draft-ietf-emu-gpsk: in IETF Last Call (ends 2008-11-03), on agenda of 2008-11-06 IESG telechat. - EMU WG received a liaison statement reply from ITU-T SG 17 regarding X.1034, "Guidelines on EAP-based authentication and key management in a data communication network". - (not WG item) draft-arkko-eap-aka-kdf went through IETF Last call; now doing final checks to make sure everything is aligned here and in relevant 3GPP specs. IPSECME - (not wearing AD hat) I need to check that my comments got entered into the issue tracker, and reply to Paul about some of them. - (not wearing AD hat) Waiting for Russ to verify errata #1502 for RFC 4718 [since 2008-09-12] ISMS - I haven't managed to read the mailing list at all this month; I really need to do so. KEYPROV - I need to put more time into KEYPROV in November and December; the WG is over a year behind its milestones, and it doesn't look like the documents are anywhere near ready. SASL - SASL WG was rechartered. SYSLOG - draft-ietf-syslog-transport-tls: was approved and is now in RFC Editor Queue - draft-ietf-syslog-sign: there has been a bunch of replies to my AD evaluation comments that I need to read and process, but I haven't done so yet. However, I'm hoping to see a revised ID that would address those concerns where everyone agrees what should be done. - draft-ietf-ipcdn-pktc-eventmess: this is in RFC Editor Queue, but had references to documents syslog WG decided to drop -- big thanks to David Harrington and Richard Woundy for getting this fixed. TLS - draft-ietf-tls-des-idea: in Publication Requested state, waiting for Tim to review this (since I'm the editor) [since 2008-10-20] - draft-ietf-tls-ecdhe-psk: hoping the WG will soon request publication and send the shepherd write-up etc. - draft-ietf-tls-psk-new-mac-aes-gcm: same as ecdhe-psk. - Certicom has posted an updated statement about ECC IPR (http://www.certicom.com/index.php/ip-contributions), which probably will also appear in the IETF IPR tool soon. Joe Salowey has asked them about including draft-ietf-tls-ecdhe-psk in the list of documents. - (not WG item) draft-rescorla-tls-suiteb: on agenda of 2008-11-06 IESG telechat. OTHER DOCUMENTS - draft-ietf-avt-rtcpssm: Joerg replied on 2008-10-27 about the "feedback debug" messages; I need to read his email and reply. - draft-ietf-pkix-cmp-transport-protocols: It seems some folks are interested in reviving this long-expired draft, so that current implementation behavior is documented somewhere. I've promised to read and comment if/when something is submitted. - draft-randall-3447bis: James Randall posted the -00 draft; I should read this and comment. - draft-ietf-mpls-mpls-and-gmpls-security-framework: I've promised to read this once there's a new version. - "Security roadmap for routing protocols": I've promised to read and comment this once Gregory sends something. - draft-mattsson-srtp-store-and-forward: I've promised to read this and send comments, but haven't done so yet. DISCUSSES (active -- something happened within last month) - draft-ietf-enum-experiences: the authors have replied to my updated discuss; I need to read their message and reply [since 2008-10-27] - draft-ietf-dime-mip6-integrated: waiting for authors to submit a revised ID [since 2008-10-29] - draft-ietf-mip6-whyauthdataoption: waiting for authors to submit a revised ID, and reply to some of my comments [since 2008-10-29] - draft-ietf-mipshop-mstp-solution: I need to check version -08 and talk with Jari and the authors about what's the best way to handle this document [since 2008-10-20] - draft-ietf-pce-pcep: version -16 addressed all my major concerns; I hope to see a revised ID fixing the remaining things before the submission cut-off date [since 2008-10-30] - draft-ietf-simple-imdn: version -09 addressed most of my comments; waiting for the authors to reply to the remaining ones [since 2008-10-27] - draft-ietf-sip-fork-loop-fix: version -08 was submitted recently; I need to check that my concerns were addressed [since 2008-10-29] - 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 from Mary or Jon [since 2008-10-28] - draft-ietf-tsvwg-emergency-rsvp: I moved to "abstain" position. DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-cain-post-inch-phishingextns: waiting for authors to reply to my comments or submit a revised ID [since 2008-08-28] - draft-cam-winget-eap-fast-provisioning: waiting for authors to reply to my comments or submit a revised ID [since 2008-08-28] - draft-ietf-lemonade-msgevent: waiting for authors to submit a revised ID [since 2008-09-08] - draft-ietf-sieve-refuse-reject: waiting for authors to reply to my comments [since 2008-09-11] - draft-zhou-emu-fast-gtc: changes probably agreed, waiting for authors to submit a revised ID to see exact text [since 2008-08-28] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-ietf-bfd-base: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-multihop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-v4v6-1hop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-shim6-proto: waiting for Erik to propose something to solve IPsec interaction issue [since 2008-06-18] --end-- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag