From kaduk@mit.edu Mon Apr 1 10:01:12 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A7311E80CC; Mon, 1 Apr 2013 10:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28l6HrMA6vCq; Mon, 1 Apr 2013 10:01:12 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id CAE1411E80AE; Mon, 1 Apr 2013 10:01:10 -0700 (PDT) X-AuditID: 12074425-b7fec6d000007584-37-5159bd558297 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id CD.E9.30084.55DB9515; Mon, 1 Apr 2013 13:01:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r31H19Wr015051; Mon, 1 Apr 2013 13:01:09 -0400 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r31H17fJ016511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Apr 2013 13:01:08 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r31H17tr006109; Mon, 1 Apr 2013 13:01:07 -0400 (EDT) Date: Mon, 1 Apr 2013 13:01:06 -0400 (EDT) From: Benjamin Kaduk To: ietf@ietf.org In-Reply-To: <20130319142244.19905.39903.idtracker@ietfa.amsl.com> Message-ID: References: <20130319142244.19905.39903.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUixCmqrRu6NzLQ4PN9c4tnG+ezWHxY+JDF gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZG74/YSn4zFNxeN9D5gbGY1xdjBwcEgImEl3rmLoY OYFMMYkL99azdTFycQgJ7GOU6PjxjBEkISSwgVHiR4cwROIgk8SBBWeZIBL1Ej/ubGMGsVkE tCRmnW8Fs9kEVCRmvtnIBrJAREBQ4uBjSxCTWUBYYt9RJ5AxwgJdjBKNa2ayg5RzCjhJ/O+9 BzaSV8BBYuPOLqi9jhL7zh5hA7FFBXQkVu+fwgJRIyhxcuYTMJtZwFLi39pfrBMYBWchSc1C klrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWldBMjKDTZXVR3ME44pHSIUYCD UYmH12FOZKAQa2JZcWXuIUZJDiYlUd5Tu4FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhXZALl eFMSK6tSi/JhUtIcLErivDdSbvoLCaQnlqRmp6YWpBbBZGU4OJQkeOfuAWoULEpNT61Iy8wp QUgzcXCCDOcBGr4DpIa3uCAxtzgzHSJ/ilFRSpy3AyQhAJLIKM2D64WljleM4kCvCPOuAKni AaYduO5XQIOZgAYvuxUOMrgkESEl1cAocGWr1QXzX9zysnwditJpu5Nnxr+axckXn3k+ZKbk N4Xv2y7Zn9oe8frB7TjFi+9NM803MvwW/sSw5piR2pN7yz99ZKj8ILCISVTtQewLrcdCQbe2 v6q78UHsy0efhqJ1Ou8bFY8pP2tinKr4mFPUe0nXlhPa89b9mhFhsDhW5MLMrXc8L7c+UWIp zkg01GIuKk4EACl6mS/4AgAA X-Mailman-Approved-At: Mon, 01 Apr 2013 11:37:12 -0700 Cc: secdir@ietf.org Subject: Re: [secdir] [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:01:12 -0000 I have not yet completed a full review of this (320-page) document, and I worry that I may not finish before the deadline, so I am bringing this concern to your attention now. Section 3.2.1.1 of this document ("Kerberos V5 as a security triple") seems to indicate that it is mandatory for a conformant NFSv4 implementation to implement the Kerberos V5 GSS-API mechanism and a few "security triples" (mechanism,quality of protection,service). All of the mandatory-to-implement security triples use the DES-MAC-MD5 algorithm. The draft goes on to indicate that clients should engage in security negotiation (section 3.3) to determine what security to use for bulk operation, and that since kerberos-v5 under RPCSEC_GSS is mandatory, the negotiation will be performed using that security provider. The actual mechanism resulting from the negotiation may be different (or may be the same), but this single-DES mechanism seems to be required to be used to protect the negotiation step. Given that the kerberos working group has published RFC 6649 (Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos) and single-DES is known to be critically vulnerable to brute-force attacks, I have grave concern about the IETF publishing new standards documents that mandate the implementation of single-DES and do not specify strong cryptographic algorithms. I feel that to do so would be misleading implementors into believing that single-DES is sufficient and other mechanisms need not be implemented, when in reality this is not true. Sincerely, Ben Kaduk MIT Kerberos Consortium From alexey.melnikov@isode.com Tue Apr 2 06:13:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEB221F84BC; Tue, 2 Apr 2013 06:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPcLBYI9bODQ; Tue, 2 Apr 2013 06:13:28 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAE221F8700; Tue, 2 Apr 2013 06:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1364908405; d=isode.com; s=selector; i=@isode.com; bh=RiKMAjcFEXvq8ERlhTg4IhLUD2vgtq994PPyh5f6eBw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=IbBGjYTP2k3UrRc/XUv6QzWOYo0ewPKru8Ki8HMk3KTz8DKJbXnIfGY+Sq7JK3lyXfiJCs 8v2JZM2hHaQq5EHLHJS+B64JHrt65ldsdZBKhp5Wuh0pDJ4/GHg7X2S99X9K2k/dct/1Xz 7UTOhWPuXeNksz7mIYQNrNtElP4GCjU=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 2 Apr 2013 14:13:25 +0100 Message-ID: <515AD9A2.4030003@isode.com> Date: Tue, 02 Apr 2013 14:14:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: The IESG , secdir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-core-coap.all@tools.ietf.org Subject: [secdir] Security review of draft-ietf-core-coap-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:13:29 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines the Constrained Application Protocol (CoAP), which is a specialized web transfer protocol (basically a binary protocol that provides a subset of HTTP functionality) for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine applications such as smart energy and building automation. The Security Consideration points to Section 15 of RFC 2616 (among other things). I think this is quite appropriate, as RFC 2616 covers lots of relevant issues, including disclosure of sensitive information. The Security Consideration section correctly points out that Protocol Parsing complexity can lead to vulnerabilities, in particular parsing/processing of URIs. Section 11.3 talks about risk of amplification attacks (causing bigger packets to be sent to a victim based on smaller packets sent by an attacker) and possible mitigations. Section 11.4 talks about IP Address Spoofing Attacks (message spoofing, making endpoints "deaf", cache poisoning, etc.). Section 11.2 talks about Proxying and Caching attacks (Denial-of-service, threat to confidentiality and integrity of request/response data). Many mitigation techniques depend on use of DTLS (modes other than NoSec), but this is fine, as one of DTLS modes is mandatory to implement for all compliant CoAP nodes. I appreciated text describing possible cross protocol attacks, in particular when DNS packets are sent to a CoAP endpoint. Section 9 (Securing CoAP) talks about several modes of securing CoAP with DTLS. It talks about how certificate verification should be done and provisioning of raw public keys. These sections seem to be well written and sufficiently detailed to implement. Overall I think that the document has very good and detailed security considerations. Minor issues/nits: 9.1.3.2. Raw Public Key Certificates In this mode the device has an asymmetric key pair but without an X.509 certificate (called a raw public key). A device MAY be configured with multiple raw public keys. The type and length of the raw public key depends on the cipher suite used. Implementations in RawPublicKey mode MUST support the mandatory to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [I-D.mcgrew-tls-aes-ccm-ecc], It looks like this reference is Normative, while you have it as Informative. [RFC5246], [RFC4492]. The mechanism for using raw public keys with TLS is specified in [I-D.ietf-tls-oob-pubkey]. 9.1.3.2.1. Provisioning The RawPublicKey mode was designed to be easily provisioned in M2M deployments. It is assumed that each device has an appropriate asymmetric public key pair installed. An identifier is calculated from the public key as described in Section 2 of [I-D.farrell-decade-ni]. All implementations that support checking RawPublicKey identities MUST support at least the sha-256-120 mode (SHA-256 truncated to 120 bits). Implementations SHOULD support also I think you need a Normative reference to SHA-256 here. longer length identifiers and MAY support shorter lengths. Note that the shorter lengths provide less security against attacks and their use is NOT RECOMMENDED. Best Regards, Alexey P.S. I have some Apps specific issues with the document, but I send these separately in my AppsDir review. From Sandra.Murphy@sparta.com Tue Apr 2 15:13:11 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE56C21F84D8; Tue, 2 Apr 2013 15:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0JzJx3LAuTD; Tue, 2 Apr 2013 15:13:10 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id C453621F8920; Tue, 2 Apr 2013 15:13:09 -0700 (PDT) Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r32MD6fA016161; Tue, 2 Apr 2013 17:13:06 -0500 Received: from Hermes.columbia.ads.sparta.com ([10.62.56.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r32MD6tN013984; Tue, 2 Apr 2013 17:13:06 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%18]) with mapi id 14.02.0247.003; Tue, 2 Apr 2013 18:12:39 -0400 From: "Murphy, Sandra" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-pkix-rfc2560bis@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-pkix-rfc2560bis Thread-Index: AQHOL+3Ho5kEetJxf0C+edDRCbGdew== Date: Tue, 2 Apr 2013 22:12:39 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F66EDF44E1@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-pkix-rfc2560bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 22:13:11 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any= other last call comments.=0A= =0A= This draft is a bis for 2560 and 6277 and updates 5912 as well. Most of th= e text is adopted wholesale from the obsoleted rfcs.=0A= =0A= Many of my comments below apply to text that passed muster in the obsoleted= RFCs, so take that into consideration.=0A= =0A= --Sandy=0A= =0A= =0A= =0A= =0A= sec 1 p 4=0A= =0A= In general, I am unsure what it means to say "as specified in rfc6277"=0A= when this draft is supposed to obsolete rfc6277.=0A= =0A= I also found the "as specified in" language to be ambiguous as to whether= =0A= the referenced work was the original use that this draft changes or the=0A= extended/changed use that this draft adopts or copies.=0A= =0A= o Section 2.2 extends the use of the "revoked" response to allow=0A= this response status certificates that has never been issued.=0A= =0A= That second line is missing something, perhaps "response status to refer to= =0A= certificates that have never".=0A= =0A= o Section 4.2.1 and 4.2.2.3 states that a response may include=0A= state=0A= revocation status information for certificates that were not=0A= included in the request=0A= =0A= I could find no reference in 4.2.1 to including info on un-requested=0A= certificates. =0A= =0A= o Section 4.2.2.3 clarify that the ResponderID field corresponds=0A= clarifies=0A= =0A= o Section 4.3 changes set of cryptographic algorithms that=0A= ^the=0A= clients must support and the set of cryptographic algorithms=0A= that clients should support as specified in [RFC6277].=0A= =0A= Section 4.3 is NOT as specified in RFC6277. It updates what RFC6277=0A= mandates.=0A= =0A= o Section 4.4.7 specifies a new extension that may be included in=0A= a request message to specify signature algorithms the client=0A= would prefer the server use to sign the response as specified=0A= in [RFC6277].=0A= =0A= This use of "as specified" was particularly unclear. I think it means=0A= o Section 4.4.7 specifies a new extension, originally specified=0A= in RFC6277, that may be included in=0A= =0A= o Section B.2 provides an ASN.1 module using the 2008 syntax of=0A= ASN.1 which updates [RFC5912]=0A= =0A= Sounds like the 2008 syntax updates RFC5912. "Section B.2, which=0A= updates rfc5912, provides"?=0A= =0A= sec 2.1 p 6=0A= =0A= An OCSP request contains the following data:=0A= =0A= -- protocol version=0A= -- service request=0A= -- target certificate identifier=0A= -- optional extensions which MAY be processed by the OCSP Responder=0A= =0A= There is no separate "service request" field in the request - the cert=0A= id and the extensions are the service request. Maybe they are=0A= intended to be indented to show structure? I.e.,=0A= =0A= -- protocol version=0A= -- service request=0A= +++ target certificate identifier=0A= +++ optional extensions which MAY be processed by the OCSP Respond= er=0A= =0A= Upon receipt of a request, an OCSP Responder determines if;=0A= =0A= 1. the message is well formed,=0A= =0A= 2. the responder is configured to provide the requested service, and;=0A= =0A= There is no hint later that there might be multiple oscp services=0A= that a responder might be providing, so not sure what this means.=0A= =0A= sec 2.1-2.2, p 6=0A= =0A= If any one of these conditions are not met, the OCSP responder=0A= produces an error message; otherwise, it returns a definitive=0A= response.=0A= =0A= 2.2 Response=0A= =0A= OCSP responses can be of various types. An OCSP response consists of=0A= a response type and the bytes of the actual response. There is one=0A= basic type of OCSP response that MUST be supported by all OCSP=0A= servers and clients. The rest of this section pertains only to this=0A= =0A= After some reading, I decided that the "definitive response" and the=0A= "basic type of OCSP response" are the same thing, and it is (they are)=0A= distinct from error messages. If so, then section 2.2's title really=0A= should be "Definitive Response" or "Basic Response".=0A= =0A= sec 2.2 p 7=0A= =0A= The "good" state indicates a positive response to the status inquiry.=0A= At a minimum, this positive response indicates that the certificate=0A= is not revoked, but does not necessarily mean that the certificate=0A= was ever issued=0A= ...=0A= The "revoked" state indicates=0A= ...=0A= This state MAY also be returned if the associated=0A= CA has no record of ever having issued a certificate with the=0A= certificate serial number in the request,=0A= ...=0A= The "unknown" state indicates that the responder doesn't know about=0A= the certificate being requested.=0A= =0A= If I read this right, a request for a non-issued cert might produce=0A= any status - good, revoked, or unknown.=0A= =0A= There is a lot of discussion of provisions for responding with "revoked"=0A= for a non-issued certificate and some additional detail that might give=0A= the client a clue that "revoked" meant "non-issued". But a response of=0A= "good" and "unknown" are IMPLICIT NULL - so there is no way to provide=0A= any such clue. Am I reading the intent (and the ASN.1) right?=0A= =0A= sec 2.2 p 8=0A= =0A= the SingleResponse related to this non-issued certificate;=0A= =0A= SingleResponse is not defined yet and will not be until p 14.=0A= =0A= sec 2.3, p 9=0A= =0A= The response "sigRequired" is returned in cases where the server=0A= requires the client sign the request in order to construct a=0A= =0A= "requires that the client sign" or "requires the client to sign"=0A= =0A= sec 2.4 p 9=0A= =0A= Responses can contain three times in them - thisUpdate, nextUpdate=0A= and producedAt.=0A= =0A= I was not sure what "can contain" meant - any of the three? a choice of=0A= just one of the three? etc. According to sec 4.2.1, p 14,=0A= the thisUpdate and producedAt are required, nextUpdate is optional.=0A= This statement could be clearer.=0A= =0A= sec 2.5 p 10=0A= =0A= field of the response. The time at or before which newer information=0A= will be available is reflected in the nextUpdate field,=0A= might be=0A= MAY be=0A= =0A= unless you are saying that in pre-production the nextUpdate field=0A= is not optional.=0A= =0A= sec 2.6 p 10=0A= =0A= A certificate's issuer=0A= explicitly delegates OCSP signing authority by issuing a certificate=0A= containing a unique value for extendedKeyUsage=0A= =0A= I wondered whether this meant any unique value would do or a specific=0A= unique well-known value. section 4.2.2.2.2 p15 says it is a well-known=0A= unique value. It would be great to clear up this text to make that=0A= clear (e.g., a reference to 4.2.2.2).=0A= =0A= sec 3.1 p 10=0A= =0A= In order to convey to OCSP clients a well-known point of information=0A= access, CAs SHALL provide the capability to include the=0A= AuthorityInfoAccess extension (defined in [RFC5280], section 4.2.2.1)=0A= =0A= Is it sufficient to "provide the capability to include"? Then who=0A= (and why and when) makes use of that capability? I.e., who actually=0A= includes the capability? I think maybe this means "CAs SHALL include=0A= the AuthorityInfoAccess extension".=0A= =0A= in certificates that can be checked using OCSP.=0A= =0A= Some certificate a CA issues can be checked using OCSP and some can=0A= not?=0A= =0A= CAs that support an OCSP service, either hosted locally or provided=0A= by an Authorized Responder, MUST provide for the inclusion of a value=0A= for a uniformResourceIndicator (URI) [RFC3986] accessLocation and the=0A= OID value id-ad-ocsp for the accessMethod in the AccessDescription=0A= SEQUENCE.=0A= =0A= Is it OK to just "provide for the inclusion of a value" but never=0A= actually include the value? I.e., does this actually mean a responder=0A= MUST include a (value for a) URI accessLocator with/and an accessMethod=0A= with the value ... I'm not sure what the intent is here, much less=0A= the proper way to talk about ASN.1 structures.=0A= =0A= sec 3.2 p 11=0A= =0A= 1. The certificate identified in a received response corresponds to=0A= that which was identified in the corresponding request;=0A= =0A= I was never sure how a response was mapped to a request. The transport=0A= mechanisms mentioned aren't always connection oriented. p 18 says that=0A= a repsonse must include status for every cert in the request, so it is=0A= important to be able to map response to request. Is this a stop-and-wait= =0A= protocol so the client never has more than one outstanding request?=0A= =0A= 3. The identity of the signer matches the intended recipient of the=0A= request.=0A= =0A= Sec 4.4.6 says that it is possible for the client to send a request to=0A= one server and have the request forwarded to another. And there's the=0A= possibility of getting a response from an Authorized Responder rather than= =0A= the CA for the certificate. So who is the "intended recipient"?=0A= =0A= sec 4.1.1 p 12=0A= =0A= issuerNameHash OCTET STRING, -- Hash of Issuer's DN=0A= issuerKeyHash OCTET STRING, -- Hash of Issuers public key=0A= Issuer's=0A= <>=0A= =0A= sec 4.2.1 p 13=0A= =0A= An OCSP response at a minimum consists of a responseStatus field=0A= indicating the processing status of the prior request.=0A= =0A= "*the* prior request" - further evidence that this is a stop-and-wait=0A= protocol?=0A= =0A= If the value=0A= of responseStatus is one of the error conditions, responseBytes are=0A= not set.=0A= =0A= MUST NOT be set? =0A= =0A= For a basic OCSP responder, responseType will be id-pkix-ocsp-basic.=0A= response?=0A= =0A= If I read this right, a basic (aka definitive) response means the=0A= status is "successful". So if the status is "successful", is it that=0A= the responseType *MUST* be id-pkix-ocsp-basic?=0A= =0A= sec 4.2.1 p 14=0A= =0A= The value for signature SHALL be computed on the hash of the DER=0A= encoding ResponseData.=0A= ^of=0A= =0A= CertStatus ::=3D CHOICE {=0A= good [0] IMPLICIT NULL,=0A= revoked [1] IMPLICIT RevokedInfo,=0A= unknown [2] IMPLICIT UnknownInfo }=0A= ...=0A= UnknownInfo ::=3D NULL=0A= =0A= So there is no way for a status of "good" or "unkown" to indicate that=0A= the certificate was never actually issued.=0A= =0A= sec 4.2.2.1 p 15=0A= =0A= The thisUpdate and nextUpdate fields define a recommended validity=0A= interval. This interval corresponds to the {thisUpdate, nextUpdate}=0A= interval in CRLs. Responses whose nextUpdate value is earlier than=0A= the local system time value SHOULD be considered unreliable.=0A= Responses whose thisUpdate time is later than the local system time=0A= SHOULD be considered unreliable.=0A= =0A= What about the relationship between producedAt and {thisUpdate,=0A= nextUpdate}? I would think that thisUpdate <=3D producedAt <=3D=0A= nextUpdate, but is it an error if it is not? What about the=0A= relationship of producedAt to the local time?=0A= =0A= sec 4.2.2.2 p 15-16=0A= =0A= The CA SHOULD use the same issuing key to issue a delegation=0A= certificate as was used to sign the certificate being checked for=0A= revocation. =0A= ...=0A= clients are not required=0A= to recognize a responder with such certificate as an authorized=0A= responder.=0A= =0A= If I read this right, clients must map an authorized responder's=0A= delegation certificate to a CA only if the CA uses the same key to=0A= issue its certs and the authorized responder's delegation=0A= certificate, but the clients are permitted to ignore a mismatch and=0A= accept the authorized responder anyway. (So if the clients might=0A= accept anyway, why require that they check?)=0A= =0A= only if the delegation certificate and the=0A= certificate being checked for revocation was signed by the same key.=0A= were=0A= =0A= sec 4.2.2.2 p 16=0A= =0A= 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage=0A= extension and is issued by the CA that issued the certificate in=0A= question as stated above."=0A= ^ (don't think this is a quote)=0A= =0A= sec 4.2.2.2 p 17=0A= =0A= revocation. This can be done using CRL Distribution Points if the=0A= check should be done using CRLs or CRL Distribution Points,=0A= ^^^^^^^^^^^^^^^^^^^^^^^^^^=0A= =0A= I don't understand this - use CRL Distr Points if the check should=0A= use CRL Distr Points? I wonder if that "or DRL Distribution Points"=0A= part is supposed to be there.=0A= =0A= sec 4.2.2.3 p 17=0A= =0A= find the certificate used to sign a signed OCSP response. Therefor,=0A= Therefore,=0A= =0A= The purpose of the ResponderID information is to allow clients to=0A= find the certificate used to sign a signed OCSP response. Therefor,=0A= the information MUST correspond to the certificate that was used to=0A= sign the response.=0A= =0A= There are those in the pkix community who object to this sort of=0A= expression that a cert is used to sign anything, and insist that=0A= language instead say the cert is used to validate signatures. (I=0A= wonder how this paragraph got past such people.) That is "find the=0A= certificate to be used (that could be used) to validate the signature=0A= on a signed OCSP response" and "MUST correspond to the certificate=0A= that could (should) be used to validate the signature on the signed=0A= response".=0A= =0A= sec 4.2.2.3 p 18=0A= =0A= The response MUST include a SingleResponse for each certificate in=0A= the request and SHOULD NOT include any additional SingleResponse=0A= elements.=0A= =0A= More about associating request and response. May a response include=0A= SingleResponses for certs mentioned in more than one request, as long=0A= as it includes a response for all the certs in each request?=0A= =0A= sec 4.4.1 p 18=0A= =0A= The nonce cryptographically binds a request and a response to prevent=0A= replay attacks. The nonce is included as one of the requestExtensions=0A= in requests, while in responses it would be included as one of the=0A= responseExtensions. =0A= =0A= MUST the nonce be included in a response if it is included in the=0A= request? (See previous comments about associating response with request).= =0A= Is the response invalid if it includes a nonce but the request did not=0A= include a nonce?=0A= =0A= sec 4.4.3=0A= =0A= An OCSP client MAY wish to specify the kinds of response types it=0A= understands.=0A= =0A= There is only one response type defined right now, right? Is this=0A= included just in case other response types are eventually supported?=0A= =0A= sec 4.4.6 p 20=0A= =0A= ServiceLocator ::=3D SEQUENCE {=0A= issuer Name,=0A= locator AuthorityInfoAccessSyntax OPTIONAL }=0A= =0A= Appendix B p 33 does not say OPTIONAL=0A= =0A= sec 4.4.7 p 20=0A= =0A= it's algorithm preferences, there is always a risk that a server=0A= its ^ (no comma)=0A= =0A= sec 4.4.7 p 21=0A= =0A= o Rules for signature algorithm selection that maximizes the=0A= maximize=0A= =0A= sec 4.4.7.1 p 22=0A= =0A= PreferredSignatureAlgorithm ::=3D SEQUENCE {=0A= sigIdentifier AlgorithmIdentifier,=0A= pubKeyAlgIdentifier SMIMECapability OPTIONAL=0A= }=0A= =0A= This agrees with 6277 but does not agree with Appendix B p 33, which says= =0A= =0A= PreferredSignatureAlgorithm ::=3D SEQUENCE {=0A= sigIdentifier AlgorithmIdentifier,=0A= certIdentifier AlgorithmIdentifier OPTIONAL }=0A= =0A= sec 4.4.7.1 p 22=0A= =0A= The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of=0A= RFC 5280 [RFC5280] The syntax of SMIMECapability is defined in RFC=0A= . (missing period)=0A= 5751 [RFC5751]=0A= . (missing period)=0A= =0A= sec 4.4.7.2 p 22-23=0A= =0A= 4.4.7.2 Responder Signature Algorithm Selection=0A= =0A= RFC 2560 [RFC2560] did not specify a mechanism for deciding the=0A= signature algorithm=0A= ...=0A= by selecting a supported signature algorithm using the following=0A= ...=0A= 1. Select an algorithm specified as a preferred signing algorithm in=0A= ...=0A= 2. Select the signing algorithm=0A= ...=0A= 3. Select the signing algorithm=0A= ...=0A= 4. Select a signature algorithm=0A= ...=0A= 5. Select a mandatory or recommended signing algorithm =0A= =0A= Consistency being the hobgoblin of little minds, I wonder if there's=0A= a need for consistent use of "signature algorithm" and "signing algorithm".= =0A= =0A= (Once I noticed this, I saw it lots of other places.)=0A= =0A= 5. Select a mandatory or recommended signing algorithm specified for=0A= the version of the OCSP protocol in use=0A= =0A= A responder SHOULD always apply the lowest numbered selection=0A= mechanism that results in the selection of a known and supported=0A= algorithm that meets the responder's criteria for cryptographic=0A= algorithm strength.=0A= =0A= Suppose an algorithm is mandatory to *use*?=0A= =0A= sec 5 p 25=0A= =0A= Unsigned error responses open up the protocol to another=0A= denial of service attack, where the attacker sends false error=0A= responses.=0A= =0A= I did wonder about this when I saw that error responses need not be=0A= signed. I would expect that the security considerations section would=0A= include recommendations of appropriate ways to mitigate the threat of=0A= false error responese. You can rate limit floods of queries (or floods=0A= of responses from spoofed queries) but this DoS takes just one response.=0A= =0A= The use of precomputed responses allows replay attacks in which an=0A= old (good) response is replayed prior to its expiration date but=0A= after the certificate has been revoked.=0A= =0A= Does "its expiration date" refer to the expiration of the cert in the=0A= request or the expiration of the response (i.e, current time is past=0A= the nextUpdate time)=0A= =0A= Requests do not contain the responder they are directed to. This=0A= allows an attacker to replay a request to any number of OCSP=0A= responders.=0A= =0A= The risk being an amplification attack where the client receives=0A= a flood of responses?=0A= =0A= The reliance of HTTP caching in some deployment scenarios may result=0A= on? (caching doesn't do any relying, does it)=0A= in unexpected results if intermediate servers are incorrectly=0A= configured or are known to possess cache management faults.=0A= Implementors are advised to take the reliability of HTTP cache=0A= mechanisms into account when deploying OCSP over HTTP.=0A= ^^^^^^^^^=0A= =0A= I don't think implementers are the ones doing deploying, so I suspect=0A= this should say "implementing".=0A= =0A= Responding with a "revoked" state to certificate that has never been=0A= status to a=0A= =0A= =0A= 5.1 Preferred Signature Algorithms=0A= =0A= The mechanism used to choose the response signing algorithm MUST be=0A= =0A= See previous comments about consistency of terms.=0A= =0A= =0A= sec 5.1.1 p 26=0A= =0A= Such a certificate might employ a signing method=0A= that is no longer considered acceptably secure. In such=0A= circumstances the responder MUST NOT generate a signature using a=0A= signing mechanism that is not considered acceptably secure.=0A= =0A= Do "signing method" or "signing mechanism" mean the same thing=0A= as signing/signature algorithm, or do method/mechanism imply something=0A= distinct from algorithm?=0A= =0A= sec 5.1.3 p 27=0A= =0A= Algorithm agility mechanisms defined in this document introduces a=0A= introduce=0A= =0A= sec 7 p 28-29=0A= =0A= 7.1. Normative References=0A= ...=0A= [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,=0A= Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext=0A= Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.=0A= ...=0A= 7.2. Informative References=0A= ...=0A= [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,=0A= Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext=0A= Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.=0A= =0A= I don't think rfc2616 can be in both sections.=0A= =0A= 7.1. Normative References=0A= ...=0A= [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate=0A= Status Protocol Algorithm Agility", RFC 6277, June 2011.=0A= ...=0A= 7.2. Informative References=0A= =0A= [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.=0A= Adams, "X.509 Internet Public Key Infrastructure Online=0A= Certificate Status Protocol - OCSP", RFC 2560, June 1999.=0A= =0A= This draft obsoletes both rfc6277 and rfc2560. Why is rfc2560 considered= =0A= informative but rfc6277 is considered normative?=0A= =0A= App B p 33=0A= =0A= ServiceLocator ::=3D SEQUENCE {=0A= issuer Name,=0A= locator AuthorityInfoAccessSyntax }=0A= =0A= This does not agree with sec 4.4.6 p 20.=0A= =0A= PreferredSignatureAlgorithm ::=3D SEQUENCE {=0A= sigIdentifier AlgorithmIdentifier,=0A= certIdentifier AlgorithmIdentifier OPTIONAL }=0A= =0A= This does not agree with sec 4.4.7.1 p 22.=0A= =0A= App C p 40=0A= =0A= Published specification: IETF PKIX Working Group Draft on Online=0A= Certificate Status Protocol - OCSP=0A= ...=0A= Published specification: IETF PKIX Working Group Draft on Online=0A= Certificate Status Protocol - OCSP=0A= =0A= I don't quite know the reason why this mentions the wg draft rather=0A= than the published rfc - will the eventual registration point to the=0A= new published RFC? The requirements for media type registration=0A= (RFC4288) say that a standards track RFC is required.=0A= From cabo@tzi.org Wed Apr 3 09:32:28 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2A21F8F4D; Wed, 3 Apr 2013 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojmdp5MNsFQZ; Wed, 3 Apr 2013 09:32:28 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3526521F8F44; Wed, 3 Apr 2013 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r33GWMfb003447; Wed, 3 Apr 2013 18:32:22 +0200 (CEST) Received: from [192.168.217.105] (p548925A8.dip.t-dialin.net [84.137.37.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6FDA239D6; Wed, 3 Apr 2013 18:32:22 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <515AD9A2.4030003@isode.com> Date: Wed, 3 Apr 2013 18:32:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12392981-A884-47C7-BE99-98988F5411D1@tzi.org> References: <515AD9A2.4030003@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Wed, 03 Apr 2013 09:43:13 -0700 Cc: draft-ietf-core-coap.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-core-coap-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:32:29 -0000 Alexey, thank you for this thoughtful review. Re your two minor items: > raw public key depends on the cipher suite used. Implementations in > RawPublicKey mode MUST support the mandatory to implement cipher > suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in > [I-D.mcgrew-tls-aes-ccm-ecc], >=20 > It looks like this reference is Normative, while you have it as = Informative. We will add this as a normative reference in draft-ietf-core-coap-15. > asymmetric public key pair installed. An identifier is calculated > from the public key as described in Section 2 of > [I-D.farrell-decade-ni]. All implementations that support checking > RawPublicKey identities MUST support at least the sha-256-120 mode > (SHA-256 truncated to 120 bits). Implementations SHOULD support = also >=20 > I think you need a Normative reference to SHA-256 here. Actually, we specifically require the sha-256-120 mode from = draft-farrell-decade-ni (the parenthetical remark is just explanatory), = which is a normative reference and in turn has SHA-256 (FIPS PUB 180-3) = as a normative reference. (We also reference RFC 6347, which does not reference SHA-256, but = references RFC 5246, which finally references FIPS PUB 180-2. Of = course, we could reference FIPS PUB 180-4, if that helps, but we would = like to avoid the "transitive closure" effect. Or maybe = draft-farrell-decade-ni should be updated to FIPS PUB 180-4 before = publication. Or maybe not, which is another reason not to try doing the = transitive closure.) > P.S. I have some Apps specific issues with the document, but I send = these separately in my AppsDir review. Looking forward to it! Gr=FC=DFe, Carsten From nico@cryptonector.com Wed Apr 3 14:07:13 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5635A21F8F21; Wed, 3 Apr 2013 14:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Tgn4sNuCTjT; Wed, 3 Apr 2013 14:07:12 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id B05C021F8F10; Wed, 3 Apr 2013 14:07:12 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 6CFA021DE6A; Wed, 3 Apr 2013 14:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=BbKACLYqkV8M3QhUNqi/ C8xXqRI=; b=FJ7r+MMapQUDgNWLHc86aK7YqtbRYE1XiJUuYI3rTDTtcRhzZVMP k1Xybx95hfBEl5ClHLGV6K5oOrEFmlkHnDI8mPFhDJHkYinloafIxwzFyb23ZBGq tLHe+RqBaUcFhj1i5E1gakQe2NvxR7Ij4oriP8VzqUeZtqfx8vvhzno= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id E275521DE58; Wed, 3 Apr 2013 14:07:11 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id p43so1547518wea.10 for ; Wed, 03 Apr 2013 14:07:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.77.226 with SMTP id v2mr24814528wiw.33.1365023230434; Wed, 03 Apr 2013 14:07:10 -0700 (PDT) Received: by 10.217.105.195 with HTTP; Wed, 3 Apr 2013 14:07:10 -0700 (PDT) In-Reply-To: References: <20130319142244.19905.39903.idtracker@ietfa.amsl.com> Date: Wed, 3 Apr 2013 16:07:10 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:07:13 -0000 On Mon, Apr 1, 2013 at 12:01 PM, Benjamin Kaduk wrote: > Section 3.2.1.1 of this document ("Kerberos V5 as a security triple") seems > to indicate that it is mandatory for a conformant NFSv4 implementation to > implement the Kerberos V5 GSS-API mechanism and a few "security triples" > (mechanism,quality of protection,service). All of the > mandatory-to-implement security triples use the DES-MAC-MD5 algorithm. The > draft goes on to indicate that clients should engage in security negotiation > (section 3.3) to determine what security to use for bulk operation, and that > since kerberos-v5 under RPCSEC_GSS is mandatory, the negotiation will be > performed using that security provider. The actual mechanism resulting from > the negotiation may be different (or may be the same), but this single-DES > mechanism seems to be required to be used to protect the negotiation step. Oh, well, this is just outdated text. And indeed, the GSS-API's notion of "qop" (quality of protection) is broken: it's used in the wrong place (per-msg token functions). The GSS qop brokenness is why this text persists. OLD: 1 == number of pseudo flavor 2 == name of pseudo flavor 3 == mechanism's OID 4 == mechanism's algorithm(s) 5 == RPCSEC_GSS service 1 2 3 4 5 -------------------------------------------------------------------- 390003 krb5 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_none 390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_integrity 390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_privacy for integrity, and 56 bit DES for privacy. NEW: 1 == number of pseudo flavor 2 == name of pseudo flavor 3 == mechanism's OID 4 == qop 5 == RPCSEC_GSS service 1 2 3 4 5 -------------------------------------------------------------------- 390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_none 390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_integrity 390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_privacy KITTEN WG should undertake an extension to replace the broken qop concept. Nico -- From kivinen@iki.fi Thu Apr 4 01:51:41 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D1121F95F4 for ; Thu, 4 Apr 2013 01:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUUlk3wQJskx for ; Thu, 4 Apr 2013 01:51:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3A321F95E8 for ; Thu, 4 Apr 2013 01:51:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r348paHw001313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Apr 2013 11:51:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r348pZ6E011898; Thu, 4 Apr 2013 11:51:35 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20829.16151.532456.849042@fireball.kivinen.iki.fi> Date: Thu, 4 Apr 2013 11:51:35 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 08:51:41 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Ondrej Sury is next in the rotation. For telechat 2013-04-11 Reviewer LC end Draft Warren Kumari T 2013-03-26 draft-merkle-ikev2-ke-brainpool-03 Julien Laganier T 2013-03-18 draft-ietf-appsawg-webfinger-12 For telechat 2013-04-25 Yoav Nir T 2013-04-16 draft-ietf-nfsv4-rfc3530bis-25 Magnus Nystrom T 2013-04-16 draft-ietf-nfsv4-rfc3530bis-dot-x-16 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Dan Harkins R2013-04-01 draft-ietf-ipfix-flow-selection-tech-14 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Ben Laurie 2013-03-29 draft-ietf-ospf-ipv4-embedded-ipv6-routing-09 Matt Lepinski 2013-03-15 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10 Kathleen Moriarty 2013-04-03 draft-ietf-dnsext-dnssec-algo-signal-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-02 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Eric Rescorla 2013-04-10 draft-ietf-6renum-gap-analysis-05 Vincent Roca 2013-04-08 draft-ietf-pcp-upnp-igd-interworking-07 Joe Salowey 2013-04-12 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 Yaron Sheffer 2013-04-15 draft-ietf-sipcore-sip-websocket-08 Nico Williams - draft-ietf-httpbis-p5-range-22 -- kivinen@iki.fi From Tom.Haynes@netapp.com Wed Apr 3 21:14:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D1711E80A5; Wed, 3 Apr 2013 21:14:57 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAkkJbe6Is58; Wed, 3 Apr 2013 21:14:55 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id BAA6021F8A4F; Wed, 3 Apr 2013 21:14:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,405,1363158000"; d="scan'208";a="36922071" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 03 Apr 2013 21:14:55 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r344EtB7008861; Wed, 3 Apr 2013 21:14:55 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.175]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Wed, 3 Apr 2013 21:14:54 -0700 From: "Haynes, Tom" To: Benjamin Kaduk Thread-Topic: [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard Thread-Index: AQHOJK1Hk1lo2vsfCEaGISRIWfn6TZjCIP0AgAPg6QA= Date: Thu, 4 Apr 2013 04:14:54 +0000 Message-ID: <830AD203-2C2A-428F-A952-08B8F5A727E9@netapp.com> References: <20130319142244.19905.39903.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F13949B2D100146887AC8DB4086D04F@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 04 Apr 2013 02:21:03 -0700 Cc: "ietf@ietf.org" , nfsv4 list , "secdir@ietf.org" Subject: Re: [secdir] [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 04:14:57 -0000 On Apr 1, 2013, at 10:01 AM, Benjamin Kaduk wrote: > I have not yet completed a full review of this (320-page) document, and I= worry that I may not finish before the deadline, so I am bringing this con= cern to your attention now. >=20 > Section 3.2.1.1 of this document ("Kerberos V5 as a security triple") see= ms to indicate that it is mandatory for a conformant NFSv4 implementation t= o implement the Kerberos V5 GSS-API mechanism and a few "security triples" = (mechanism,quality of protection,service). All of the mandatory-to-impleme= nt security triples use the DES-MAC-MD5 algorithm. The draft goes on to ind= icate that clients should engage in security negotiation (section 3.3) to d= etermine what security to use for bulk operation, and that since kerberos-v= 5 under RPCSEC_GSS is mandatory, the negotiation will be performed using th= at security provider. The actual mechanism resulting from the negotiation = may be different (or may be the same), but this single-DES mechanism seems = to be required to be used to protect the negotiation step. >=20 > Given that the kerberos working group has published RFC 6649 (Deprecate D= ES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos) and = single-DES is known to be critically vulnerable to brute-force attacks, I h= ave grave concern about the IETF publishing new standards documents that ma= ndate the implementation of single-DES and do not specify strong cryptograp= hic algorithms. I feel that to do so would be misleading implementors into= believing that single-DES is sufficient and other mechanisms need not be i= mplemented, when in reality this is not true. >=20 > Sincerely, >=20 > Ben Kaduk > MIT Kerberos Consortium Hi Ben, Thanks for pointing this out - the last work on Kerberos for this bis was done before RFC 6649 was published. While I can propose that we modify the text to point to take RFC 6649 into consideration and to deprecate DES for Kerberos in NFSv4 implementations, this will in no way invalidate the use of DES in shipping implementations based solely on RFC 3530. We did have the following in RFC 3530: Users and implementors are warned that 56 bit DES is no longer considered state of the art in terms of resistance to brute force attacks. Once a revision to [RFC1964] is available that adds support for AES, implementors are urged to incorporate AES into their NFSv4 over Kerberos V5 protocol stacks, and users are similarly urged to migrate to the use of AES. And in RFC 5661, we have this wording: At the time NFSv4.1 was specified, the Advanced Encryption Standard (AES) with HMAC-SHA1 was a REQUIRED algorithm set for Kerberos V5. In contrast, when NFSv4.0 was specified, weaker algorithm sets were REQUIRED for Kerberos V5, and were REQUIRED in the NFSv4.0 specification, because the Kerberos V5 specification at the time did not specify stronger algorithms. The NFSv4.1 specification does not specify REQUIRED algorithms for Kerberos V5, and instead, the implementor is expected to track the evolution of the Kerberos V5 standard if and when stronger algorithms are specified. And instead of referencing RFC 1964, it instead references: [5] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS- API) Mechanism Version 2", RFC 4121, July 2005. My proposal is that we adopt the language from RFC 5661: At the time of this document, the Advanced Encryption Standard (AES) with HMAC-SHA1 was a REQUIRED algorithm set for Kerberos V5. In contrast, when NFSv4.0 was first specified, weaker algorithm sets wer= e REQUIRED for Kerberos V5, and were REQUIRED in the NFSv4.0 specification, because the Kerberos V5 specification at the time did not specify stronger algorithms. The NFSv4.0 specification no longer specifies REQUIRED algorithms for Kerberos V5, and instead, the implementor is expected to track the evolution of the Kerberos V5 standard if and when stronger algorithms are specified. In essence, the proposal is to replace Section 3.2 in 3530bis with that of Section 2.2.1 of 5661. You would not see DES in the new content. Does this alleviate your concern? Thanks, Tom= From nico@cryptonector.com Thu Apr 4 09:41:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BBE21F8D1C; Thu, 4 Apr 2013 09:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjV3wGuTjSKO; Thu, 4 Apr 2013 09:41:29 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1A70C21F8D14; Thu, 4 Apr 2013 09:41:29 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id BA3BB27BC056; Thu, 4 Apr 2013 09:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZimHsvHYRfFbFV8Ovqco Egeb7ZM=; b=mVN5YBUMoc9xNTTMOwwlNiHYLaXgVDDHntKZAvzWk7iKH+c+hww6 u7FRwN+l2I04b1HwwqprioJBDDYHx6lgzimoJSMGxkiCPBnJER+Bg3yRC8rGrFFf 2RE3TWAzk/r7XgHoj3brkbu6zTxTeLMB9iamiUK9+5tZ8q+BDe4TvMA= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id AF79327BC075; Thu, 4 Apr 2013 09:41:23 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id d46so2235529wer.30 for ; Thu, 04 Apr 2013 09:41:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.158.161 with SMTP id wv1mr10890652wjb.38.1365093681860; Thu, 04 Apr 2013 09:41:21 -0700 (PDT) Received: by 10.217.105.195 with HTTP; Thu, 4 Apr 2013 09:41:21 -0700 (PDT) In-Reply-To: References: <20130319142244.19905.39903.idtracker@ietfa.amsl.com> Date: Thu, 4 Apr 2013 11:41:21 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:41:29 -0000 On Wed, Apr 3, 2013 at 4:07 PM, Nico Williams wrote: > Oh, well, this is just outdated text. And indeed, the GSS-API's > notion of "qop" (quality of protection) is broken: it's used in the > wrong place (per-msg token functions). The GSS qop brokenness is why > this text persists. > > OLD: ... > NEW: ... Actually, I should also propose some text explaining why qop is a busted concept and what qop 0 means ("default"). Nico -- From kaduk@mit.edu Thu Apr 4 10:36:16 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D064121F93CC; Thu, 4 Apr 2013 10:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTN4PWpYu8e5; Thu, 4 Apr 2013 10:36:16 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 99D4C21F93C7; Thu, 4 Apr 2013 10:36:15 -0700 (PDT) X-AuditID: 1209190e-b7f266d0000008cb-4d-515dba0e507c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 58.16.02251.E0ABD515; Thu, 4 Apr 2013 13:36:14 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r34HaC0k009503; Thu, 4 Apr 2013 13:36:13 -0400 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r34Ha9GV029365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Apr 2013 13:36:11 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r34Ha8KQ027661; Thu, 4 Apr 2013 13:36:08 -0400 (EDT) Date: Thu, 4 Apr 2013 13:36:08 -0400 (EDT) From: Benjamin Kaduk To: "Haynes, Tom" , Nico Williams In-Reply-To: <830AD203-2C2A-428F-A952-08B8F5A727E9@netapp.com> Message-ID: References: <20130319142244.19905.39903.idtracker@ietfa.amsl.com> <830AD203-2C2A-428F-A952-08B8F5A727E9@netapp.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT1+XbFRto0HZAzeLZxvksFrPfP2K1 OHXtCJvFh4UPWSxOHTnN4sDq8fLUOUaPJUt+MnnM+PSFLYA5issmJTUnsyy1SN8ugSvjxoWX LAXPDCq2d05lbmDsV+ti5OSQEDCRWNi1nR3CFpO4cG89WxcjF4eQwD5Gib/X9jBDOBsYJT49 fQTlHGSS+ND3kRWkRUigXuLrlYVsIDaLgJbE175uRhCbTUBFYuabjWBxEYFIifOt+5lAbGaB PIknd+eDrRAW6GKUaFwzE2w3p4CdRMfR+ywgNq+Ag8TlmdtZIbatYJR4dHE9WEJUQEdi9f4p UEWCEidnPmGBmGop8W/tL9YJjIKzkKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGus l5tZopeaUrqJERTWnJJ8Oxi/HlQ6xCjAwajEw5vRFxsoxJpYVlyZe4hRkoNJSZT36UagEF9S fkplRmJxRnxRaU5q8SFGCQ5mJRHepZuAcrwpiZVVqUX5MClpDhYlcd4rKTf9hQTSE0tSs1NT C1KLYLIyHBxKErzHdgA1ChalpqdWpGXmlCCkmTg4QYbzAA1n3QkyvLggMbc4Mx0if4pRUUqc dzNIswBIIqM0D64XlnZeMYoDvSLM2wtSxQNMWXDdr4AGMwENnno3GmRwSSJCSqqB0a+Iazbr 0tVX9/0+OOmxQgTrlkVhjhb21ka7HqXy/J2xcZYz58yYP1G/JWqe26ueOzCV5XnF5kAB/jev KvTUG3dkqD90EN4eZLb5OEfCPecd2xwLFVyCPY44TI6wPvkpZDqL4rWZJbfVF8tV1qWbr9vl Zpbz2pxDs9zpTPfUCb1C8ZdWPvoXocRSnJFoqMVcVJwIACpS8msWAwAA Cc: "ietf@ietf.org" , nfsv4 list , "secdir@ietf.org" Subject: Re: [secdir] [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:36:17 -0000 Hi Tom, Nico, On Thu, 4 Apr 2013, Haynes, Tom wrote: > > On Apr 1, 2013, at 10:01 AM, Benjamin Kaduk wrote: > [snip. Single-DES is weak and deprecated] > > > Hi Ben, > > Thanks for pointing this out - the last work on Kerberos for this bis > was done before RFC 6649 was published. It did look like the Kerberos portions of the document had not been touched since the previous revision; RFC 6649 was probably later in coming than it should have been. > While I can propose that we modify the text to point to take RFC 6649 > into consideration and to deprecate DES for Kerberos in NFSv4 > implementations, this will in no way invalidate the use of DES in shipping > implementations based solely on RFC 3530. Understood. The DES-migration process has been and continues to be a long process; on the Kerberos side we're mostly done, but applications still need to adapt. (I'm working on updates for AFS, which had DES baked into it pretty thoroughly.) Thus, part of the work of the Kerberos folks is to actively encourage people to migrate away from DES -- though there's not much we can do about old standards still being used, new standards should encourage migration. In this vein, my preference would be for this document to actively mention migration away from DES, though I understand that this is a stronger sentiment than is strictly speaking necessary. Part of my concern stems from the fact that there are existing NFSv4 implementations which remain DES-only, and I would like this document to strongly encourage those implementations to add support for strong crypto. > We did have the following in RFC 3530: > > Users and implementors are warned that 56 bit DES is no longer > considered state of the art in terms of resistance to brute force > attacks. Once a revision to [RFC1964] is available that adds support > for AES, implementors are urged to incorporate AES into their NFSv4 > over Kerberos V5 protocol stacks, and users are similarly urged to > migrate to the use of AES. > > And in RFC 5661, we have this wording: > > At the time NFSv4.1 was specified, the Advanced Encryption Standard > (AES) with HMAC-SHA1 was a REQUIRED algorithm set for Kerberos V5. > In contrast, when NFSv4.0 was specified, weaker algorithm sets were > REQUIRED for Kerberos V5, and were REQUIRED in the NFSv4.0 > specification, because the Kerberos V5 specification at the time did > not specify stronger algorithms. The NFSv4.1 specification does not > specify REQUIRED algorithms for Kerberos V5, and instead, the > implementor is expected to track the evolution of the Kerberos V5 > standard if and when stronger algorithms are specified. > > And instead of referencing RFC 1964, it instead references: > > [5] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version > 5 Generic Security Service Application Program Interface (GSS- > API) Mechanism Version 2", RFC 4121, July 2005. > > My proposal is that we adopt the language from RFC 5661: > > At the time of this document, the Advanced Encryption Standard > (AES) with HMAC-SHA1 was a REQUIRED algorithm set for Kerberos V5. > In contrast, when NFSv4.0 was first specified, weaker algorithm sets were > REQUIRED for Kerberos V5, and were REQUIRED in the NFSv4.0 > specification, because the Kerberos V5 specification at the time did > not specify stronger algorithms. The NFSv4.0 specification no longer > specifies REQUIRED algorithms for Kerberos V5, and instead, the > implementor is expected to track the evolution of the Kerberos V5 > standard if and when stronger algorithms are specified. > > In essence, the proposal is to replace Section 3.2 in 3530bis with > that of Section 2.2.1 of 5661. You would not see DES in the new > content. > > Does this alleviate your concern? The quoted text would be a big improvement, but does not seem like a complete solution -- the table would need to be updated to remove the algorithm column, probably as per Nico's suggestion. It also seems like section 2.2.1.1.1.2.1.1 of RFC 5661 is still applicable: When deploying NFSv4.1, the strength of the security achieved depends on the existing Kerberos V5 infrastructure. The algorithms of Kerberos V5 are not directly exposed to or selectable by the client or server, so there is some due diligence required by the user of NFSv4.1 to ensure that security is acceptable where needed. This would be a good place to reference RFC 6649 and/or mention that modern Kerberos implementations disable weak algorithms by default, as part of the "active encouragement" that I would prefer. On Wed, 3 Apr 2013, Nico Williams wrote: > Oh, well, this is just outdated text. And indeed, the GSS-API's > notion of "qop" (quality of protection) is broken: it's used in the > wrong place (per-msg token functions). The GSS qop brokenness is why > this text persists. > [snip] > > NEW: > 1 == number of pseudo flavor > 2 == name of pseudo flavor > 3 == mechanism's OID > 4 == qop > 5 == RPCSEC_GSS service > > 1 2 3 4 5 > -------------------------------------------------------------------- > 390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_none > 390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_integrity > 390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_privacy > > Actually, I should also propose some text explaining why qop is a > busted concept and what qop 0 means ("default"). The table in RFC 5661 also includes columns for whether the flavor is mandatory for clients and servers, but it looks like they are now always mandatory and those columns are not needed. In combination with Tom's proposed changes, this table should work well. Agreed that some text about what qop 0 means is needed. > KITTEN WG should undertake an extension to replace the broken qop concept. I worry that such an undertaking would degenerate into a full GSS-API rewrite, but regardless that's out of scope for the current discussion. Thanks for the updates, Ben From nico@cryptonector.com Thu Apr 4 11:50:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA8221F8D40; Thu, 4 Apr 2013 11:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IbXi2z0CAHp; Thu, 4 Apr 2013 11:50:57 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 26DD021F8D1C; Thu, 4 Apr 2013 11:50:57 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 7811C36007C; Thu, 4 Apr 2013 11:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=yQzikiiRZQ28Q3cggg6w 9L1F3vo=; b=ierx04cCAY+sR7zonCafRR8tVZ/qyhYrxB0+J/hydq5+ah/RQtnK JeedkF9zAiNu8VFNP/RUJAvxDCBhfObbDP93gvJxSouSdoDks73MQ5eeEEg28yWW KmSzhw+RH5Yr2Se28aSnlp98Cx+ElabWZBSGMkjTAj3YMoNU5+VpYbI= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 1C25F360014; Thu, 4 Apr 2013 11:50:52 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so3130431wgh.5 for ; Thu, 04 Apr 2013 11:50:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr11523044wjb.29.1365101451215; Thu, 04 Apr 2013 11:50:51 -0700 (PDT) Received: by 10.217.105.195 with HTTP; Thu, 4 Apr 2013 11:50:51 -0700 (PDT) In-Reply-To: References: <20130319142244.19905.39903.idtracker@ietfa.amsl.com> <830AD203-2C2A-428F-A952-08B8F5A727E9@netapp.com> Date: Thu, 4 Apr 2013 13:50:51 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: "Haynes, Tom" , "ietf@ietf.org" , nfsv4 list , "secdir@ietf.org" Subject: Re: [secdir] [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 18:50:57 -0000 On Thu, Apr 4, 2013 at 12:36 PM, Benjamin Kaduk wrote: > In combination with Tom's proposed changes, this table should work well. I agree. > Agreed that some text about what qop 0 means is needed. I yes. Indeed, maybe we should even remove the qop column and state that we always use qop 0 unless otherwise stated (and we'll not state otherwise). >> KITTEN WG should undertake an extension to replace the broken qop concept. > > I worry that such an undertaking would degenerate into a full GSS-API > rewrite, but regardless that's out of scope for the current discussion. I don't think so. We've discussed it [since] on IRC, and it's not relevant here so I'll not burden the cc'ed with it. I'll bring something to KITTEN WG about this *after* the interim meeting that's coming up, but NFSv4 WG should not wait for it. Nico -- From benl@google.com Fri Apr 5 08:00:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6D921F9802 for ; Fri, 5 Apr 2013 08:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTHn98kPHQ8q for ; Fri, 5 Apr 2013 08:00:29 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 40FA321F97F2 for ; Fri, 5 Apr 2013 08:00:29 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id x24so3239471iak.38 for ; Fri, 05 Apr 2013 08:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=SrdxXRM6xMysrZFSkpkqEkEYZ70KyEGzHW0uxfJ+1E0=; b=mF7jH/zugGQ4JUJetSmg8+LNlvON/gmelM9OxW0ZgP+DNlSvmSNTGmgHwfUsuX/W8Q 4REeRGlBjZeTF5ZaJmzeCmf4qKMHtpJ7r37aSj9Izj8k6C+3dhfFj2FAS6EGgsErT3NX JL4IRoYbmQG2NRqaAObo4PvehLFDl2hPkz79colBUSmPkEUxTcrB00WDIZlSZ94DMqt0 r9gH5zSNMN8wt/BeBRzPU4rSUDmtc6Bfm7VOofXPShkTU7Y2dD35XZ6nHQzM5NP7flPh sqUfVRNm/Lw4kVrdEiRW3L6knIrV+T2LnepW0Qvcb4mlo4yQEsbWFMWFUjpypdGbQocn i2sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=SrdxXRM6xMysrZFSkpkqEkEYZ70KyEGzHW0uxfJ+1E0=; b=bltDmlYLSzF5vv9JfvjcV1tZpgIiShSssLkXdC/WcNw/4DmuVsiehj8BwFfUz5rajK I0WBWO8/wAjLXFC2vdA7EmqLqYPNul+PVEtUpnZ/LAzHqpsegJ3lDBXKLeeFM/rcJw7h JEYkEDY/KkSeRlDwb2LOObhbfBHP2QB/hXYmlCYuudti+sWr7Y60vZBNVtddcQCzfN4s KzwNFeT8Ml3s4VpXhOMCcxqNAJcWJafUbiv50CW0w6+eR7DL1K9P713YQJJh4y8jSO4M sWTWaJ5kErQp0aZ4DgaqnIFh96kaniDHkJqWaMYaN8TxOsEFJOqW6LeujGmnvHXU01mT WRjw== MIME-Version: 1.0 X-Received: by 10.50.70.9 with SMTP id i9mr1795053igu.60.1365174028732; Fri, 05 Apr 2013 08:00:28 -0700 (PDT) Received: by 10.64.20.131 with HTTP; Fri, 5 Apr 2013 08:00:28 -0700 (PDT) Date: Fri, 5 Apr 2013 16:00:28 +0100 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-ospf-ipv4-embedded-ipv6-routing.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn+wiel/7JyQml30nLNfRGevfBlai37eZ03UpJW80UEDPJ4+v63gOypF6BJaNvBCkDTtrrJ2VxJUu47Rjw/dvf4viEtlJlDAENlMIG7RILYXvVABFuPM1BnXZxGwYdea28HC5y0I1dad67R7QLXj3FIMvr9oy2MCPyemGbYGs0xoG9/fMKyLpyLHc4yqBRig1Fmrgy6 Subject: [secdir] Secdir review of draft-ietf-ospf-ipv4-embedded-ipv6-routing-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:00:29 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: I-D is ready with potential nits. Detail: as far as I can tell, this I-D does not introduce any new mechanism and instead describes a particular configuration of existing mechanisms. As such, it is hard for it to introduce security issues that do not already exist. However, it is entirely possible the document's advice is not optimal - I'm afraid my knowledge of IPv6 is too limited to be a good judge of that. The security considerations section does mention some potential pitfalls, but it is hard to judge whether they are comprehensive, and I would suggest they should be. I would advise the security ADs to have it reviewed by an IPv6 security expert. From stephen.farrell@cs.tcd.ie Sun Apr 7 07:55:52 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C8F21F8EC6 for ; Sun, 7 Apr 2013 07:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbQHuEDxJj9U for ; Sun, 7 Apr 2013 07:55:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E5B8821F8DE4 for ; Sun, 7 Apr 2013 07:55:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 42F67BE5D for ; Sun, 7 Apr 2013 15:55:30 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHrL7MOqermA for ; Sun, 7 Apr 2013 15:55:29 +0100 (IST) Received: from [10.87.48.5] (unknown [86.46.27.148]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65F57BE5B for ; Sun, 7 Apr 2013 15:55:29 +0100 (IST) Message-ID: <516188E0.4040503@cs.tcd.ie> Date: Sun, 07 Apr 2013 15:55:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] organising mentoring X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 14:55:52 -0000 Hiya, Following on from Orlando's plenary discussion Brian Haberman is trying to see if he can find a set of people from each IETF area who'd be willing to help find mentors for people who've been involved in the IETF for a year or less. We'd like a couple of SEC area volunteers for this if we can get 'em. At this point Brian is looking for someone who'd be able to matchmake between experienced IETFers and new folks who're interested in security, so this is more about knowing experienced IETFers that could be hassled to become mentors and less about mentoring. (Though I expect whoever volunteers for this will also end up doing mentoring too.) If you'd be willing, just send a mail to Sean and I. Thanks, S. From kathleen.moriarty@emc.com Sun Apr 7 09:33:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB0421F84CC for ; Sun, 7 Apr 2013 09:33:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8fmL4z4kVSw for ; Sun, 7 Apr 2013 09:33:43 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8EA21F84B2 for ; Sun, 7 Apr 2013 09:33:42 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r37GXbCD027034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 7 Apr 2013 12:33:37 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Sun, 7 Apr 2013 12:33:22 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r37GXLnv026465 for ; Sun, 7 Apr 2013 12:33:22 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Sun, 7 Apr 2013 12:33:21 -0400 From: "Moriarty, Kathleen" To: "secdir@ietf.org" Date: Sun, 7 Apr 2013 12:33:20 -0400 Thread-Topic: [secdir] organising mentoring Thread-Index: Ac4zoDT+0ongReq3TBe3OcNF7g4JVAAC718Q Message-ID: References: <516188E0.4040503@cs.tcd.ie> In-Reply-To: <516188E0.4040503@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [secdir] organising mentoring X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 16:33:44 -0000 In case it is helpful, I went to a session on mentoring at the Simmons Wome= n's conference last week and here are some of the highlights (at least to m= e). People should take the "Implicit association test" to learn where they are = biased on their own. Understanding the benefits of mentoring is helpful: O Link it to organizational outcomes O Use it to help navigate a turbulent environment O Can be used as a way to confront stereotypes O Represents an investment in important assets Start with a goal for mentoring with a timeframe of 12-16 months in mind. As the mentee, know what you need help with. If you write it down, more li= kely to do it. If you are the one doing the mentoring, you may want to sta= rt with this exercise. Mentee should have 2 items when they show up to each mentor sessions They should schedule time for reflection and understand that time is the bi= ggest challenge for them and the Mentor. Examples were given where the men= tee would meet the mentor in places convenient for the mentor, like the air= port, where they had time to focus on the mentee. Having a "deep level similarity" is good for mentor/mentee relationship, an= d as I reflect I think this is true for me as both a mentee and mentor. It= could mean different things in each relationship and may not be at all rel= ated to the topic for which is mentored (family, religion, economic backgro= und, where you are from, etc.). =20 As a mentor, you need to convey info in a way it can be heard. The speaker= referred to cases where difficult advice was conveyed to her in a way that= she would be receptive to it. You may have to put a lot of thought into t= he personality types of someone you mentor to do this effectively. You may= mis-step on the first try, but think about your delivery and how the messa= ge can be heard.=20 Think about how are you leveraging the mentoring you are receiving? I hope this is helpful to some! =20 Best regards, Kathleen -----Original Message----- From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of= Stephen Farrell Sent: Sunday, April 07, 2013 10:55 AM To: secdir@ietf.org Subject: [secdir] organising mentoring Hiya, Following on from Orlando's plenary discussion Brian Haberman is trying to see if he can find a set of people from each IETF area who'd be willing to help find mentors for people who've been involved in the IETF for a year or less. We'd like a couple of SEC area volunteers for this if we can get 'em. At this point Brian is looking for someone who'd be able to matchmake between experienced IETFers and new folks who're interested in security, so this is more about knowing experienced IETFers that could be hassled to become mentors and less about mentoring. (Though I expect whoever volunteers for this will also end up doing mentoring too.) If you'd be willing, just send a mail to Sean and I. Thanks, S. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From ynir@checkpoint.com Mon Apr 8 03:35:58 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5D021F87D0; Mon, 8 Apr 2013 03:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-iQlp7kOj+z; Mon, 8 Apr 2013 03:35:57 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D75D021F87D3; Mon, 8 Apr 2013 03:35:56 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r38AZNZi013157; Mon, 8 Apr 2013 13:35:54 +0300 X-CheckPoint: {51629D58-9-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Mon, 8 Apr 2013 13:35:36 +0300 From: Yoav Nir To: "secdir@ietf.org" , The IESG , "draft-ietf-nfsv4-rfc3530bis.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-nfsv4-rfc3530bis-25 Thread-Index: AQHONETOGWagEh4py0udbBA2y+BXSQ== Date: Mon, 8 Apr 2013 10:35:36 +0000 Message-ID: <4DCE9E87-2EF9-4E40-8A33-AB3AF4A11F88@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.136] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SecDir review of draft-ietf-nfsv4-rfc3530bis-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 10:35:58 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: In my opinion, this I-D needs more work. This is a huge draft. It's on track to become the 3rd biggest RFC behind th= e security glossary and the NFS 4.1 RFC (5661). I've spent more time on thi= s than my previous SECDIR reviews combined, and I still don't think I've do= ne a thorough enough job. This revision splits RFC 3530 in two: this docume= nt, and the XDR document. This is the third revision of the NFSv4 spec (aft= er 3530 and 3010). RFC 3010 was published on December 2000, over 12 years a= go. It may have been a good idea back then to write the spec as a compariso= n to previous specifications, but I don't think this makes sense 12 years l= ater. As an example, we need look no further than the Abstract: The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. And it goes on throughout the document - always a diff from NFS 3. That kin= d of voice makes sense when addressing a community with significant NFS 3 e= xperience, and little or no NFS 4 experience. Is this still the case?=20 The Introduction section does not talk at all about what NFS is and what it= could possibly be used for. It's just a series of sections detailing diffe= rences from version 3, from 3530, and from 3010. Nowhere does it say why we= need a revision of version 4, when version 4.1 is already published. Much = of the text is taken from RFC 3530, and in some places it gets weird: - Section 11 talks about requirements for future minor versions. Except th= at unlike when 3530 was published, now a minor version already exists. But = the text ignores it, and talks in the future tense. - Section 18 instructs IANA to set up a "NFSv4 Named Attribute Definition= s Registry". That registry has been up since 2009 OK. On to security things. Section 3.2.1 talks about security mechanisms. = There's this table on page 27 that lists some algorithms, and have DES and = MD5. This looks really bad for something published in 2013. I understand th= at this relates to the deployed base of Kerberos, and the IETF mailing list= has an active thread about this:=20 http://www.ietf.org/mail-archive/web/ietf/current/msg78389.html Other security issues, such as discussions of ACLs, locks, and the handling= of edge conditions (9.6.3.4) seem OK. The Security Considerations section again begins with a discussion of previ= ous versions. Beyond that, it can be summarized as these bullet points: - Authentication is end-to-end - Translation from NFS identity to local identity needs to be secure (but = it doesn't say secure against what. What is the "integrity of the translati= on"?) - These security mechanisms are optional, but SECINFO and GETATTR should (= no RFC 2119 language) be secured. - For SETCLIENTID/SETCLIENTID_CONFIRM, it's imperative (again, no RFC 2119= language) to check the principal against that of previous requests. Not being familiar with operational NFS environments, I don't see anything = missing from this. NITS: - There's this weird thing in section 1.5.1, where it says "As with previo= us versions of NFS, XDR and RPC mechanisms used for NFSv4 are those defined= in RFC5531 and RFC4506". NFSv4 was first defined in RFC 3010, so it probab= ly uses some mechanism from earlier versions of those documents. - In section 6.4.1.1, "Access mask bits other those listed above". There's= a missing "than" between the "other" and the "those". - Section 9.1.1 discusses the Client ID. The id is generated by the client= and has to be unique. Several methods of generating this ID are discussed.= Finally, on page 107 a true random number is suggested (might be better to= say "pseudo-random number") , and then the text says: However since this number ought to be the same between client incarnations, this shares the same problem as that of the using the timestamp of the software installation. Where "between client incarnations" means "across client reboots". But this= requirement ("ought to") is never explained. I get that if the id changes,= all the locks will be broken, but does any system expect locks to remain a= cross client reboots? If so, I think it should be explicitly said. Yoav From Tom.Haynes@netapp.com Mon Apr 8 09:55:40 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8563B21F942B; Mon, 8 Apr 2013 09:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvmWH9MjVFRO; Mon, 8 Apr 2013 09:55:39 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3104121F940D; Mon, 8 Apr 2013 09:55:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,432,1363158000"; d="scan'208,217";a="38442746" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 08 Apr 2013 09:55:38 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r38GtcQl020698; Mon, 8 Apr 2013 09:55:38 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.175]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Mon, 8 Apr 2013 09:55:37 -0700 From: "Haynes, Tom" To: Yoav Nir Thread-Topic: SecDir review of draft-ietf-nfsv4-rfc3530bis-25 Thread-Index: AQHONETOGWagEh4py0udbBA2y+BXSZjNAJYA Date: Mon, 8 Apr 2013 16:55:27 +0000 Message-ID: References: <4DCE9E87-2EF9-4E40-8A33-AB3AF4A11F88@checkpoint.com> In-Reply-To: <4DCE9E87-2EF9-4E40-8A33-AB3AF4A11F88@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/alternative; boundary="_000_EBFA8133C17441C7A76A89E991504386netappcom_" MIME-Version: 1.0 Cc: "draft-ietf-nfsv4-rfc3530bis.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-nfsv4-rfc3530bis-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 16:55:40 -0000 --_000_EBFA8133C17441C7A76A89E991504386netappcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yoav, Thanks for the comments. Rather than address them all, I want to talk about the main ones driving the document. On Apr 8, 2013, at 3:35 AM, Yoav Nir > wrote: I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: In my opinion, this I-D needs more work. This is a huge draft. It's on track to become the 3rd biggest RFC behind th= e security glossary and the NFS 4.1 RFC (5661). Yes, and the WG has taken pains to make sure we do not do that again. See for example draft-ietf-nfsv4-minorversion2-19 which weighs in at under 100 pages. I've spent more time on this than my previous SECDIR reviews combined, and = I still don't think I've done a thorough enough job. This revision splits R= FC 3530 in two: this document, and the XDR document. This is the third revi= sion of the NFSv4 spec (after 3530 and 3010). RFC 3010 was published on Dec= ember 2000, over 12 years ago. It may have been a good idea back then to wr= ite the spec as a comparison to previous specifications, but I don't think = this makes sense 12 years later. As an example, we need look no further tha= n the Abstract: The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. And it goes on throughout the document - always a diff from NFS 3. That kin= d of voice makes sense when addressing a community with significant NFS 3 e= xperience, and little or no NFS 4 experience. Is this still the case? While some implementors may go straight to NFSv4.1, the path is still NFSv3 to NFSv4.0. The Introduction section does not talk at all about what NFS is and what it= could possibly be used for. It's just a series of sections detailing diffe= rences from version 3, from 3530, and from 3010. Nowhere does it say why we= need a revision of version 4, when version 4.1 is already published. Valid point and the main one I want to address here. We have a lot of implementation experience in NFSv4.0 that made its way int= o NFSv4.1. We still have many NFSv4 implementations that do not have corresponding NFSv4.1 impl= ementations. We want to drive back those lessons that do not require protocol changes in= to the base document to improve interoperability. I'll look at how to add that back to the document. Tom --_000_EBFA8133C17441C7A76A89E991504386netappcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3413B5FE5CFA9949B7A55313AF0869FE@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable Yoav,

Thanks for the comments. Rather than address them all, I want to
talk about the main ones driving the document.

On Apr 8, 2013, at 3:35 AM, Yoav Nir <ynir@checkpoint.com>
 wrote:

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.  These comments were written primarily for the benefi= t of the security area directors.  Document editors and WG chairs should treat these comments just like any other last= call comments.

Summary: In my opinion, this I-D needs more work.

This is a huge draft. It's on track to become the 3rd biggest RFC behind th= e security glossary and the NFS 4.1 RFC (5661).


Yes, and the WG has taken pains to make sure we do not do that again.<= /div>
See for example draft-ietf-nfsv4-minorversion2-19 which= weighs in at
under 100 pages.


I've spent more time on this than my previous SEC= DIR reviews combined, and I still don't think I've done a thorough enough j= ob. This revision splits RFC 3530 in two: this document, and the XDR docume= nt. This is the third revision of the NFSv4 spec (after 3530 and 3010). RFC 3010 was published on December 2= 000, over 12 years ago. It may have been a good idea back then to write the= spec as a comparison to previous specifications, but I don't think this ma= kes sense 12 years later. As an example, we need look no further than the Abstract:

  The Network File System (NFS) version 4 is a distributed filesy= stem
  protocol which owes heritage to NFS protocol version 2, RFC 109= 4, and
  version 3, RFC 1813.  Unlike earlier versions, the NFS ver= sion 4
  protocol supports traditional file access while integrating sup= port
  for file locking and the mount protocol.

And it goes on throughout the document - always a diff from NFS 3. That kin= d of voice makes sense when addressing a community with significant NFS 3 e= xperience, and little or no NFS 4 experience. Is this still the case?


While some implementors may go straight to NFSv4.1, the path is still = NFSv3
to NFSv4.0. 


The Introduction section does not talk at all about what NFS is and what it= could possibly be used for. It's just a series of sections detailing diffe= rences from version 3, from 3530, and from 3010. Nowhere does it say why we= need a revision of version 4, when version 4.1 is already published.

Valid point and the main one I want to address here.

We have a lot of implementation experience in NFSv4.0 that made its wa= y into NFSv4.1. We still
have many NFSv4 implementations that do not have corresponding NFSv4.1= implementations.

We want to drive back those lessons that do not require protocol chang= es into the base
document to improve interoperability.

I'll look at how to add that back to the document.

Tom

--_000_EBFA8133C17441C7A76A89E991504386netappcom_-- From ynir@checkpoint.com Mon Apr 8 13:35:38 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0921F935E; Mon, 8 Apr 2013 13:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ7Hdrq7H3qa; Mon, 8 Apr 2013 13:35:37 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ADCC221F9351; Mon, 8 Apr 2013 13:35:36 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r38KZYX2013898; Mon, 8 Apr 2013 23:35:34 +0300 X-CheckPoint: {516329FF-2-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Mon, 8 Apr 2013 23:35:34 +0300 From: Yoav Nir To: "Haynes, Tom" Thread-Topic: SecDir review of draft-ietf-nfsv4-rfc3530bis-25 Thread-Index: AQHONETOGWagEh4py0udbBA2y+BXSZjNAJYA//+V2IA= Date: Mon, 8 Apr 2013 20:35:33 +0000 Message-ID: <72FD367F-52F5-4C24-867E-E89BCBB39057@checkpoint.com> References: <4DCE9E87-2EF9-4E40-8A33-AB3AF4A11F88@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.104] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_72FD367F52F54C24867EE89BCBB39057checkpointcom_" MIME-Version: 1.0 Cc: "draft-ietf-nfsv4-rfc3530bis.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-nfsv4-rfc3530bis-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:35:38 -0000 --_000_72FD367F52F54C24867EE89BCBB39057checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 8, 2013, at 7:55 PM, "Haynes, Tom" > wrote: Yoav, Thanks for the comments. Rather than address them all, I want to talk about the main ones driving the document. On Apr 8, 2013, at 3:35 AM, Yoav Nir > wrote: I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: In my opinion, this I-D needs more work. This is a huge draft. It's on track to become the 3rd biggest RFC behind th= e security glossary and the NFS 4.1 RFC (5661). Yes, and the WG has taken pains to make sure we do not do that again. See for example draft-ietf-nfsv4-minorversion2-19 which weighs in at under 100 pages. That's good to know. I've spent more time on this than my previous SECDIR reviews combined, and = I still don't think I've done a thorough enough job. This revision splits R= FC 3530 in two: this document, and the XDR document. This is the third revi= sion of the NFSv4 spec (after 3530 and 3010). RFC 3010 was published on Dec= ember 2000, over 12 years ago. It may have been a good idea back then to wr= ite the spec as a comparison to previous specifications, but I don't think = this makes sense 12 years later. As an example, we need look no further tha= n the Abstract: The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. And it goes on throughout the document - always a diff from NFS 3. That kin= d of voice makes sense when addressing a community with significant NFS 3 e= xperience, and little or no NFS 4 experience. Is this still the case? While some implementors may go straight to NFSv4.1, the path is still NFSv3 to NFSv4.0. Yes. My question is whether that path has already been traversed. Looking a= t some vendor sites and Internet forums, it looks like all the major operat= ing systems (Windows, Linux, Mac OS, even IBM's exotic systems) already hav= e NFSv4. I believe the same can be said for storage products such as NetApp= . So who are those developers who have existing NFSv3 implementations, and = have not yet implemented NFSv4? The Introduction section does not talk at all about what NFS is and what it= could possibly be used for. It's just a series of sections detailing diffe= rences from version 3, from 3530, and from 3010. Nowhere does it say why we= need a revision of version 4, when version 4.1 is already published. Valid point and the main one I want to address here. We have a lot of implementation experience in NFSv4.0 that made its way int= o NFSv4.1. We still have many NFSv4 implementations that do not have corresponding NFSv4.1 impl= ementations. We want to drive back those lessons that do not require protocol changes in= to the base document to improve interoperability. I'll look at how to add that back to the document. OK. Thanks Yoav --_000_72FD367F52F54C24867EE89BCBB39057checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Apr 8, 2013, at 7:55 PM, "Haynes, Tom" <Tom.Haynes@netapp.com> wrote:

Yoav,

Thanks for the comments. Rather than address them all, I want to
talk about the main ones driving the document.

On Apr 8, 2013, at 3:35 AM, Yoav Nir <ynir@checkpoint.com>
 wrote:

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.  These comments were written primarily for the benefi= t of the security area directors.  Document editors and WG chairs should treat these comments just like any other last= call comments.

Summary: In my opinion, this I-D needs more work.

This is a huge draft. It's on track to become the 3rd biggest RFC behind th= e security glossary and the NFS 4.1 RFC (5661).


Yes, and the WG has taken pains to make sure we do not do that again.<= /div>
See for example draft-ietf-nfsv4-minorversion2-19 which= weighs in at
under 100 pages.

That's good to know.

I've spent more time on this than my previous SEC= DIR reviews combined, and I still don't think I've done a thorough enough j= ob. This revision splits RFC 3530 in two: this document, and the XDR docume= nt. This is the third revision of the NFSv4 spec (after 3530 and 3010). RFC 3010 was published on December 2= 000, over 12 years ago. It may have been a good idea back then to write the= spec as a comparison to previous specifications, but I don't think this ma= kes sense 12 years later. As an example, we need look no further than the Abstract:

  The Network File System (NFS) version 4 is a distributed filesy= stem
  protocol which owes heritage to NFS protocol version 2, RFC 109= 4, and
  version 3, RFC 1813.  Unlike earlier versions, the NFS ver= sion 4
  protocol supports traditional file access while integrating sup= port
  for file locking and the mount protocol.

And it goes on throughout the document - always a diff from NFS 3. That kin= d of voice makes sense when addressing a community with significant NFS 3 e= xperience, and little or no NFS 4 experience. Is this still the case?


While some implementors may go straight to NFSv4.1, the path is still = NFSv3
to NFSv4.0. 

Yes. My question is whether that path has already been traversed. Looking a= t some vendor sites and Internet forums, it looks like all the major operat= ing systems (Windows, Linux, Mac OS, even IBM's exotic systems) already hav= e NFSv4. I believe the same can be said for storage products such as NetApp. So who are those developers w= ho have existing NFSv3 implementations, and have not yet implemented NFSv4?=


The Introduction section does not talk at all about what NFS is and what it= could possibly be used for. It's just a series of sections detailing diffe= rences from version 3, from 3530, and from 3010. Nowhere does it say why we= need a revision of version 4, when version 4.1 is already published.

Valid point and the main one I want to address here.

We have a lot of implementation experience in NFSv4.0 that made its wa= y into NFSv4.1. We still
have many NFSv4 implementations that do not have corresponding NFSv4.1= implementations.

We want to drive back those lessons that do not require protocol chang= es into the base
document to improve interoperability.

I'll look at how to add that back to the document.

OK. Thanks

Yoav


--_000_72FD367F52F54C24867EE89BCBB39057checkpointcom_-- From Tom.Haynes@netapp.com Mon Apr 8 15:12:08 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6702621F8D8F; Mon, 8 Apr 2013 15:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDlqogLDDzVv; Mon, 8 Apr 2013 15:12:07 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C74CA21F8916; Mon, 8 Apr 2013 15:12:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,433,1363158000"; d="scan'208,217";a="38526919" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 08 Apr 2013 15:11:53 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r38MBqqA026028; Mon, 8 Apr 2013 15:11:52 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.175]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Mon, 8 Apr 2013 15:11:52 -0700 From: "Haynes, Tom" To: Yoav Nir Thread-Topic: SecDir review of draft-ietf-nfsv4-rfc3530bis-25 Thread-Index: AQHONETOGWagEh4py0udbBA2y+BXSZjNAJYA//+V2ICAAMKEgA== Date: Mon, 8 Apr 2013 22:11:44 +0000 Message-ID: <06E6B7AC-1DAD-4F82-A7BE-68BB0DD1948B@netapp.com> References: <4DCE9E87-2EF9-4E40-8A33-AB3AF4A11F88@checkpoint.com> <72FD367F-52F5-4C24-867E-E89BCBB39057@checkpoint.com> In-Reply-To: <72FD367F-52F5-4C24-867E-E89BCBB39057@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/alternative; boundary="_000_06E6B7AC1DAD4F82A7BE68BB0DD1948Bnetappcom_" MIME-Version: 1.0 Cc: "draft-ietf-nfsv4-rfc3530bis.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-nfsv4-rfc3530bis-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 22:12:08 -0000 --_000_06E6B7AC1DAD4F82A7BE68BB0DD1948Bnetappcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 8, 2013, at 1:35 PM, Yoav Nir > wrote: On Apr 8, 2013, at 7:55 PM, "Haynes, Tom" > wrote: On Apr 8, 2013, at 3:35 AM, Yoav Nir > wrote: And it goes on throughout the document - always a diff from NFS 3. That kin= d of voice makes sense when addressing a community with significant NFS 3 e= xperience, and little or no NFS 4 experience. Is this still the case? While some implementors may go straight to NFSv4.1, the path is still NFSv3 to NFSv4.0. Yes. My question is whether that path has already been traversed. Looking a= t some vendor sites and Internet forums, it looks like all the major operat= ing systems (Windows, Linux, Mac OS, even IBM's exotic systems) already hav= e NFSv4. I believe the same can be said for storage products such as NetApp= . So who are those developers who have existing NFSv3 implementations, and = have not yet implemented NFSv4? Size doesn't matter here - the developers who would write a NFSv4 implementation from scratch would come from a NFSv3 background. NFSv3 -> NFSv4 is a major release, it deserves some transition. NFSv4.1 -> NFSv4.2 is a minor release, it has almost no text wasted on tran= sition. --_000_06E6B7AC1DAD4F82A7BE68BB0DD1948Bnetappcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0E678EA02980EC479D6CA5EAE2E71BE2@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable
On Apr 8, 2013, at 1:35 PM, Yoav Nir <ynir@checkpoint.com> wrote:


On Apr 8, 2013, at 7:55 PM, "Haynes, Tom" <Tom.Haynes@netapp.com> wrote:

On Apr 8, 2013, at 3:35 AM, Yoav Nir <ynir@checkpoint.com>
 wrote:



And it goes on throughout the document - always a diff from NFS 3. That kin= d of voice makes sense when addressing a community with significant NFS 3 e= xperience, and little or no NFS 4 experience. Is this still the case?


While some implementors may go straight to NFSv4.1, the path is still = NFSv3
to NFSv4.0. 

Yes. My question is whether that path has already been traversed. Looking a= t some vendor sites and Internet forums, it looks like all the major operat= ing systems (Windows, Linux, Mac OS, even IBM's exotic systems) already hav= e NFSv4. I believe the same can be said for storage products such as NetApp. So who are those developers w= ho have existing NFSv3 implementations, and have not yet implemented NFSv4?=



Size doesn't matter here - the developers who would write a NFSv4
implementation from scratch would come from a NFSv3 background.

NFSv3 -> NFSv4 is a major release, it deserves some transition.

NFSv4.1 -> NFSv4.2 is a minor release, it has almost no text wasted= on transition.


--_000_06E6B7AC1DAD4F82A7BE68BB0DD1948Bnetappcom_-- From stephen.farrell@cs.tcd.ie Tue Apr 9 10:10:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD3321F93A6 for ; Tue, 9 Apr 2013 10:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSakDRgb0CwZ for ; Tue, 9 Apr 2013 10:10:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1411B21F937E for ; Tue, 9 Apr 2013 10:10:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 383F6BE61 for ; Tue, 9 Apr 2013 18:09:59 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1T12ObbD685 for ; Tue, 9 Apr 2013 18:09:59 +0100 (IST) Received: from [IPv6:2001:770:10:203:54d4:67d3:a46c:a5f2] (unknown [IPv6:2001:770:10:203:54d4:67d3:a46c:a5f2]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F0C33BE4C for ; Tue, 9 Apr 2013 18:09:58 +0100 (IST) Message-ID: <51644B66.1070803@cs.tcd.ie> Date: Tue, 09 Apr 2013 18:09:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "secdir@ietf.org" References: <516188E0.4040503@cs.tcd.ie> In-Reply-To: <516188E0.4040503@cs.tcd.ie> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] organising mentoring X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 17:10:22 -0000 Ping! Any takers? We're not that curmudgeonly are we:-) On 04/07/2013 03:55 PM, Stephen Farrell wrote: > > Hiya, > > Following on from Orlando's plenary discussion Brian Haberman > is trying to see if he can find a set of people from each IETF > area who'd be willing to help find mentors for people who've > been involved in the IETF for a year or less. > > We'd like a couple of SEC area volunteers for this if we can > get 'em. At this point Brian is looking for someone who'd be > able to matchmake between experienced IETFers and new folks > who're interested in security, so this is more about knowing > experienced IETFers that could be hassled to become mentors > and less about mentoring. (Though I expect whoever volunteers > for this will also end up doing mentoring too.) > > If you'd be willing, just send a mail to Sean and I. > > Thanks, > S. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > From yaronf.ietf@gmail.com Wed Apr 10 14:18:53 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F5121F8F03; Wed, 10 Apr 2013 14:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYdT6PuRM-zq; Wed, 10 Apr 2013 14:18:53 -0700 (PDT) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id B3C3221F8F02; Wed, 10 Apr 2013 14:18:52 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id l10so443680eei.22 for ; Wed, 10 Apr 2013 14:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=qsDgVFZF+NT7vdL9ctsdIwiYyvsWR4J6DWd1Wg+aKFc=; b=MPiKHNEdgFkeIllxk0OwDUoe91EkVn6GdNmAc65zi2Nl2rB4JCIC/kBztR00H33FUM FtPIroNMtqhGGKlmUGV+a0DipOrW/yfSHZ8n1qfFF7KRLKMHlWnchHLUId3z4zF/wpzk KUKWH0cAN+jhIgcvAul8g/XWAla6DCGlVCHgWgRINaKlmX5YhJIGEPV6Nr7lGZjx+DgH idxUPIitJKSoIoKl/rVKVogOxZZffsW4Yolk6up+DLvDyGIhlNStks+l9jWiQVWOIkMS 9vrfiRTT4eSwXUZO3135Ya2Ke2XoBwS3OfrWuVgkq9cwbCe/t7v8x8lkAYH6K7dl9BkO fOVg== X-Received: by 10.14.181.196 with SMTP id l44mr2108474eem.44.1365628731723; Wed, 10 Apr 2013 14:18:51 -0700 (PDT) Received: from [10.0.0.7] ([109.64.136.230]) by mx.google.com with ESMTPS id a2sm599782eem.11.2013.04.10.14.18.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 14:18:50 -0700 (PDT) Message-ID: <5165D736.9010903@gmail.com> Date: Thu, 11 Apr 2013 00:18:46 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: IETF Security Directorate , The IESG , draft-ietf-sipcore-sip-websocket.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 21:18:53 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines how SIP can be layered on the WebSocket protocol. This is essentially a profile of SIP. Summary In my opinion, from a security perspective this document is not yet ready for publication. I expect this document to be widely implemented, and I would not want it implemented until it offers a solid security model, even if it is optional. Details RFC 3261 has 20 pages of security considerations, and defines several security mechanisms. The current document "only" defines a transport for SIP, but such transport needs to preserve the security of any SIP mechanisms being used. In particular, it should be clear how endpoint identities are determined at each layer and how identities at different layers relate to one another. In other words, what's known as "channel binding". The only security-related section (other than the Security Considerations) is Authentication (Sec. 7), and this section is marked non-normative. So the reader is left to wonder: how is the SIP client authenticated? How does this authentication relate to the WebSocket-level client authentication? And similarly for the server. Sec. 9.1 mentions (again, non-normatively) that SIP-level certificate checks are omitted, and replaced by transport-level checks only. I believe this significantly reduces the security properties of SIP. Moreover, it begs for a policy tying WebSocket certificates to identities of the endpoints of the SIP protocol. Nit/bug: Sec. 5.2.1 ends with a colon in the HTML version *only*, and is missing a paragraph. Thanks, Yaron From kivinen@iki.fi Thu Apr 11 04:23:20 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2450721F8D29 for ; Thu, 11 Apr 2013 04:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7CiPpm+eRRx for ; Thu, 11 Apr 2013 04:23:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD4321F8D26 for ; Thu, 11 Apr 2013 04:23:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3BBLvlN015758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Apr 2013 14:21:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3BBLvnJ021312; Thu, 11 Apr 2013 14:21:57 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20838.40149.651386.977434@fireball.kivinen.iki.fi> Date: Thu, 11 Apr 2013 14:21:57 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 11:23:20 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview David Waltermire is next in the rotation. For telechat 2013-04-11 Reviewer LC end Draft Warren Kumari T 2013-03-26 draft-merkle-ikev2-ke-brainpool-03 Julien Laganier T 2013-03-18 draft-ietf-appsawg-webfinger-12 For telechat 2013-04-25 Magnus Nystrom T 2013-04-16 draft-ietf-nfsv4-rfc3530bis-dot-x-16 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Dan Harkins R2013-04-01 draft-ietf-ipfix-flow-selection-tech-15 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Matt Lepinski 2013-03-15 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-11 Kathleen Moriarty 2013-04-03 draft-ietf-dnsext-dnssec-algo-signal-10 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-02 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Eric Rescorla 2013-04-10 draft-ietf-6renum-gap-analysis-05 Vincent Roca 2013-04-08 draft-ietf-pcp-upnp-igd-interworking-08 Joe Salowey 2013-04-12 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 Ondrej Sury 2013-04-23 draft-ietf-manet-olsrv2-mib-06 Tina TSOU 2013-04-18 draft-ietf-mpls-tp-ring-protection-05 Carl Wallace 2013-05-07 draft-sparks-genarea-imaparch-06 Nico Williams - draft-ietf-httpbis-p5-range-22 -- kivinen@iki.fi From ibc@aliax.net Thu Apr 11 09:18:54 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E467D21F896D for ; Thu, 11 Apr 2013 09:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFjnLKW6b-gw for ; Thu, 11 Apr 2013 09:18:54 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 74AF421F91CB for ; Thu, 11 Apr 2013 09:18:53 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id bv4so375624qab.16 for ; Thu, 11 Apr 2013 09:18:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=WRUwF/K4pGfYtbQVPx+dhuUxoVFWtEgtzg7uRCtxpFo=; b=ROWUatA/q5R82cWlbRbV+cRPKxT/9RYenJz1nOMJGN3T9rQro1FGanYsdmV8xVmFHH TtSKk0ETMoLd+DP/0nLT3FqoAAD1N9j7frPAEMRDHcaruk9o1+3GLjztXhmITn++Lz6Q u84TFRMzP2kt87uwSju/e3rCXMC1D8GHbILQEX/TI27jm8AZyv6bOR9p9q2vvtWBNYRp KojGBLgopdrt532D8XDapA/5EaNqUhw2uINh3f3jUncXvjmqI/kk6XevAz3nmzvNq//f OaftZSIYW0LrrcFH8rAPq/gNzPE1iKeW+CZ7AD7m0wuJo9ByYI0g8te+9ihnrhC7NcN/ Ahfw== X-Received: by 10.224.53.11 with SMTP id k11mr7964640qag.3.1365697132347; Thu, 11 Apr 2013 09:18:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Thu, 11 Apr 2013 09:18:32 -0700 (PDT) In-Reply-To: <5165D736.9010903@gmail.com> References: <5165D736.9010903@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 11 Apr 2013 18:18:32 +0200 Message-ID: To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkViwECBsBBBECbr8xDpjXY8ug2G838VNkKY7f3uLxdOYBX53c1iHPoqYLM88ImfH9Urk2c X-Mailman-Approved-At: Thu, 11 Apr 2013 09:29:48 -0700 Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 16:18:55 -0000 2013/4/10 Yaron Sheffer : > Nit/bug: Sec. 5.2.1 ends with a colon in the HTML version *only*, and is > missing a paragraph. Hi Yaron, could you please detail again such a nit? I cannot find it, I see no errors in 5.2.1. Is it an error if 5.2.1 ends with a colon (before the "transport" BNF)? Same occurs in 5.2.2. And why is 5.2.1 missing a paragraph? Thanks a lot. PS: It will take some time to me to reply your entire mail. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Apr 11 09:52:08 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCDB21F8771 for ; Thu, 11 Apr 2013 09:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcrHHb+8Emfh for ; Thu, 11 Apr 2013 09:52:06 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 23D7921F8FAC for ; Thu, 11 Apr 2013 09:51:52 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id 6so1006827qeb.8 for ; Thu, 11 Apr 2013 09:51:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=oDx5pNovdftQVuzpQ2xvCXyX0m5am7j7rpdCmDb9x+g=; b=PEzWztWQQPH3Y6caGbkYqm41g/ZM5EmkNickSxV4nFv3XKbSgJw9i5BHNDnz8S9q+c OT4Uw9LGkKXUsYQCp4ZQKPeA0XjTtDj+Ulct5lr5pJ3PJtc8faLp4ccyapCHz/MELGKl Xsqk6C5Pp6uH/NvWhfAKdC+A825dOvWKgAvtcSCik4GFIPqKEmoCRYit/xKjYk1/G2lA 3BAOxkcPpBI0i4kGQ+WZ0TuCEP2oeKNnpW8c0mz3xAJAOt5CyOa3xdH9nTaRgy+BkGBN 88fcoqtDnQ/CvPSJBcIOZJs5iEVor79fsfOSwej9NdyWWI84GwjEyKeqly4F+4V7s0rh vuFw== X-Received: by 10.49.104.196 with SMTP id gg4mr8998636qeb.53.1365699106545; Thu, 11 Apr 2013 09:51:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Thu, 11 Apr 2013 09:51:25 -0700 (PDT) In-Reply-To: <5165D736.9010903@gmail.com> References: <5165D736.9010903@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 11 Apr 2013 18:51:25 +0200 Message-ID: To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQltcC6/qoQTPdlK6B5pHpm8k6zkTdYolfDDOSHg4M9bwKYSVj94Z+TUWVW7vI4DKk2U7xx/ Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 16:52:08 -0000 2013/4/10 Yaron Sheffer : > Details > > RFC 3261 has 20 pages of security considerations, and defines several > security mechanisms. The current document "only" defines a transport for > SIP, but such transport needs to preserve the security of any SIP mechani= sms > being used. In particular, it should be clear how endpoint identities are > determined at each layer and how identities at different layers relate to > one another. In other words, what's known as "channel binding". IMHO there is no a "channel binding". It may be or not, that's up to the implementor. For example an implementor could use the same WS connection and carry SIP registrations and calls from different SIP accounts over the same WS connection. Another implementor may associate (at server side) each WS connection with a SIP identity (for example the SIP identity could be provided in a URL parameter in the WS HTTP GET request, or retrieved from a Cookie in the same HTTP request). Honestly I don't think we should force a specific behavior here. When SIP is transported over TCP there is no rules in RFC 3261 stating that the endpoint is associated to the TCP connection, same here IMHO. > The only security-related section (other than the Security Considerations= ) > is Authentication (Sec. 7), and this section is marked non-normative. So = the > reader is left to wonder: how is the SIP client authenticated? How does t= his > authentication relate to the WebSocket-level client authentication? And > similarly for the server. IMHO we should leave this as flexible as possible. For example, as author of OverSIP (the first SIP proxy with WebSocket support) I leave the user to program it custom logic for authenticating/authorizing WebSocket connections and the SIP "layer" on top of them. From section "WebSocket authentication/authorization" at http://oversip.net/documentation/misc/sip_websocket/: ------------------------------------------------------------------ WebSocket authentication/authorization When a WebSocket client attempts to establish a WebSocket connection, OverSIP invokes user programmable callbacks. The user can there inspect parameters from the connection (including the HTTP GET request of the WebSocket handshake) in order to decide, based on any custom policy, whether to allow or deny the connection. The user can also assign custom parameters to the authorized WebSocket connection and retrieve such parameters when processing SIP requests coming through that WebSocket connection. By playing with these features several architectural solutions can be built for implementing any kind of authentication/authorization system. ------------------------------------------------------------------ > Sec. 9.1 mentions (again, non-normatively) that SIP-level certificate che= cks > are omitted, and replaced by transport-level checks only. I believe this > significantly reduces the security properties of SIP. Moreover, it begs f= or > a policy tying WebSocket certificates to identities of the endpoints of t= he > SIP protocol. I agree that this subject should be improved. In fact, web browsers allow setting user certificates for authentication in some web sites requiring them. Most probably the same is valid for WSS connections and then, a client certificate would be sent when connecting to a specific WSS server. I should investigate it a bit more. Does it sound fine? Thanks a lot. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Apr 12 06:17:32 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539F321F86A6 for ; Fri, 12 Apr 2013 06:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMf27d8dP9ed for ; Fri, 12 Apr 2013 06:17:31 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2548221F8573 for ; Fri, 12 Apr 2013 06:17:31 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bs12so863563qab.0 for ; Fri, 12 Apr 2013 06:17:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=C7W9YIaJsxPI1aOZ6P7CqujOhzJO6K1uqHhS/UZ9/Fo=; b=F5L4CycZw6T+BsYgUWeT8+Nz98r7LT5iGA6Mlquoxwo7zOV6zShOhM9Vfs29j1TSdV sluP0xMmnWZq9ZK4djiWFFRciNQmayNdYXg9bUhabMu0REwmIR0nzHYLQcmDgnOR0hRF 47CG4GjgJIksAAfONOFdcy90RgKAGi15JsXCBlaxQE2mLPf7S/zymbd+GFXhsAE2c7Mm lx4lv2rFbvSO7V3h1zDGHa6ZobclN7PNQamiCm+CMN83RJoe9jK8utj+eZRntftBdl7W jYMmA1b5Kbx6KvWFsfIQ2jRIFF0jfT3m5abdl9MMLk1uENim1nHEnocIDf5SwRmdo0qE TTtg== X-Received: by 10.224.36.6 with SMTP id r6mr11886960qad.84.1365772650533; Fri, 12 Apr 2013 06:17:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Fri, 12 Apr 2013 06:17:10 -0700 (PDT) In-Reply-To: References: <5165D736.9010903@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 12 Apr 2013 15:17:10 +0200 Message-ID: To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmQistsIha40bZmftsUvObg/zeelF00Ulmj0SPzHj5j80Jh6kIuAdFIF35qwvhMay0uMKLZ Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 13:17:32 -0000 Please let me one comment more about this at the end of this mail: 2013/4/11 I=C3=B1aki Baz Castillo : > 2013/4/10 Yaron Sheffer : > >> Details >> >> RFC 3261 has 20 pages of security considerations, and defines several >> security mechanisms. The current document "only" defines a transport for >> SIP, but such transport needs to preserve the security of any SIP mechan= isms >> being used. In particular, it should be clear how endpoint identities ar= e >> determined at each layer and how identities at different layers relate t= o >> one another. In other words, what's known as "channel binding". > > IMHO there is no a "channel binding". It may be or not, that's up to > the implementor. For example an implementor could use the same WS > connection and carry SIP registrations and calls from different SIP > accounts over the same WS connection. Another implementor may > associate (at server side) each WS connection with a SIP identity (for > example the SIP identity could be provided in a URL parameter in the > WS HTTP GET request, or retrieved from a Cookie in the same HTTP > request). > > Honestly I don't think we should force a specific behavior here. When > SIP is transported over TCP there is no rules in RFC 3261 stating that > the endpoint is associated to the TCP connection, same here IMHO. > > > >> The only security-related section (other than the Security Consideration= s) >> is Authentication (Sec. 7), and this section is marked non-normative. So= the >> reader is left to wonder: how is the SIP client authenticated? How does = this >> authentication relate to the WebSocket-level client authentication? And >> similarly for the server. > > IMHO we should leave this as flexible as possible. For example, as > author of OverSIP (the first SIP proxy with WebSocket support) I leave > the user to program it custom logic for authenticating/authorizing > WebSocket connections and the SIP "layer" on top of them. From section > "WebSocket authentication/authorization" at > http://oversip.net/documentation/misc/sip_websocket/: > > > ------------------------------------------------------------------ > WebSocket authentication/authorization > > When a WebSocket client attempts to establish a WebSocket connection, > OverSIP invokes user programmable callbacks. The user can there > inspect parameters from the connection (including the HTTP GET request > of the WebSocket handshake) in order to decide, based on any custom > policy, whether to allow or deny the connection. > > The user can also assign custom parameters to the authorized WebSocket > connection and retrieve such parameters when processing SIP requests > coming through that WebSocket connection. By playing with these > features several architectural solutions can be built for implementing > any kind of authentication/authorization system. > ------------------------------------------------------------------ About the above subject, I strongly consider that the draft MUST NOT mandate how the implementor should authenticate/authorize WebSocket connection/authentications or how he should correlate WebSocket connections with SIP identities. If we mandate that then we are limiting web developers. There are tons of ways in WWW world for authenticating and authorizing connections/sessions, IMHO we should not mandate nothing at the WebSocket layer because that is out of the scope of the draft (which indeed just defines WebSocket as a new transport for SIP, but does not attempt to deal with WebSocket authentication/authorization). Please take into account that RFC 6455 (The WebSocket Protocol) does NOT state how authentication/authorization in WebSocket sessions should be implemented. Instead it leaves full flexibility to web developers for choosing their preferred mechanism. Why should this draft mandate that at *WebSocket* level? does RFC 3261 state something about how a SIP proxy should accept or not SIP TCP connections from certain IP addresses? The draft could mandate something like: "HTTP Digest authentication is required at WebSocket level when establishing the WS handshake, and later HTTP Digest authentication MUST be used for every SIP request over such a WS connection, and both credentials must be the same and...". That would be a big error, and that would just work if we assume that "SIP over WebSocket" is just valid for creating a pure phone in a web (out of the context of the website itself) which would just become a replacement for desktop phones or softphones. That's fully wrong. There are a lot of possible scenarios for "SIP over WebSocket": - A social network, which *already* has its login/authentication/session/authorization mechanism, could include SIP over WebSocket for enabling RTC between its users. No need for Digest auth at all since the user was *already* logged in the web site and thus the server(s) can correlate the HTTP session with the WebSocket connection (via Cookies, a custom token or whatever). - Another web site could provide a "Web <--> PSTN" application in which the user has to set his SIP information (SIP account, SIP proxy, SIP password...). - etc etc So, I strongly think that the draft is correct in this subject. Mandating how authentication must be done would limit the scope of this SIP transport and would make it 100% unusable for most of the existing web deployments. Best regards. -- I=C3=B1aki Baz Castillo From magnus.westerlund@ericsson.com Fri Apr 12 06:49:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E22821F89DB; Fri, 12 Apr 2013 06:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.024 X-Spam-Level: X-Spam-Status: No, score=-106.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoDSEJWopr09; Fri, 12 Apr 2013 06:49:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEBB21F896B; Fri, 12 Apr 2013 06:49:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-8b-516810df7783 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3E.1C.10459.FD018615; Fri, 12 Apr 2013 15:49:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Apr 2013 15:49:19 +0200 Message-ID: <516810DE.3020806@ericsson.com> Date: Fri, 12 Apr 2013 15:49:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "secdir@ietf.org" , sec-ads@tools.ietf.org X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLJMWRmVeSWpSXmKPExsUyM+Jvre4DgYxAg6/LuSwuXTzLZLF88WR2 iw8LH7I4MHssWfKTyePL5c9sAUxRXDYpqTmZZalF+nYJXBn72oULWqwq/jz5xdzAuEK3i5GT Q0LAROL3qp9MELaYxIV769m6GLk4hAROMUoce3yVEcJZzijx4uUPdpAqXgFtid7fC1hBbBYB VYmXJ2cyg9hsAhYSN380soHYogLBEj9fnWGBqBeUODnzCZgtImAvMXFtM9g2ZgFNiUOfH4PV Cwu4Slx6eZQZ4gpJiS0v2tkhavQkplxtYYSw5SWat84GqxECuqGhqYN1AqPALCQrZiFpmYWk ZQEj8ypG9tzEzJz0csNNjMAgPLjlt+4OxlPnRA4xSnOwKInzhrleCBASSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXAmNuZeM16vlJp0EaT7DUsn1837Vnr399g7uR7/43O42WzutMnTUhru5nX vOLPt7hpzs8VT5mqRM+sm2zFkPfKusf16tLVu9Yy+rjfaUv0uJx/2vl18G05X+9zKwSfKpgt 4DnRs3zL8UbZ5X+evWdbceVHlAtj92zRnq88z6Z+fZrlVvm9aOeh80osxRmJhlrMRcWJAFLp WtQQAgAA Cc: "payload@ietf.org" Subject: [secdir] Security consideration template text for RTP payload formats X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 13:49:23 -0000 Secdir and Sec ADs, I have just updated the draft on Howto write RTP payload formats: https://datatracker.ietf.org/wg/payload/ I would like to request review from both some Secdir persons and at least one of the ADs regarding the security aspects of this document. The reasons are that this document contains both recommendations on what to think about when writing Security Consideration sections and template text. As this is a document that has existed a long time we have determined that the template text will be commonly used by authors of RTP payload formats. Thus I want to ensure that we have at least now have agreement on this text, especially in light of the discussion around https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/ and that we don't want secdir reviewers raising issues with this template text when you see it in the last call reviews in future years. The relevant security sections from the Howto draft are the following: 7.2. Security Considerations All Internet drafts require a Security Considerations section. The security considerations section in an RTP payload format needs to concentrate on the security properties this particular format has. Some payload formats have very few specific issues or properties and can fully fall back on the security considerations for RTP in general and those of the profile being used. Because those documents are always applicable, a reference to these is normally placed first in the security considerations section. There is suggested text in the template below. The security issues of confidentiality, integrity protection and source authentication are common issue for all payload formats. These should be solved by mechanisms external to the payload and do not need any special consideration in the payload format except for an reminder on these issues. Reasons for this division is further documented in "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [I-D.ietf-avt-srtp-not-mandatory]. For a survey of available mechanisms to meet these goals, please review "Options for Securing RTP Sessions" [I-D.ietf-avtcore-rtp-security-options]. Suitable stock text to inform people about this is included in the template. Potential security issues with an RTP payload format and the media encoding that needs to be considered are: 1. That the decoding of the payload format or its media shows substantial non-uniformity, either in output or in complexity to perform the decoding operation. For example a generic non- destructive compression algorithm may provide an output of almost an infinite size for a very limited input, thus consuming memory or storage space out of proportion with what the receiving application expected. Such inputs can cause some sort of disruption, i.e. a denial of service attack on the receiver side by preventing that host from producing any goodput. Certain decoding operations may also vary in the amount of processing needed to perform those operations depending on the input. This may also be a security risk if it is possible to raise processing load significantly above nominal simply by designing a malicious input sequence. If such potential attacks exist, this must be made clear in the security considerations section to make implementers aware of the need to take precautions against such behavior. 2. The inclusion of active content in the media format or its transport. "Active content" means scripts etc. that allow an attacker to perform potentially arbitrary operations on the receiver. Most active contents has limited possibility to access the system or perform operations outside a protected sandbox. RFC 4855 [RFC4855] has a requirement that it be noted in the media types registration if the payload format contains active content or not. If the payload format has active content it is strongly recommended that references to any security model applicable for such content are provided. A boilerplate text for "no active content" is included in the template. This must be changed if the format actually carries active content. 3. Some media formats allow for the carrying of "user data", or types of data which are not known at the time of the specification of the payload format. Such data may be a security risk and should be mentioned. 4. Audio or Speech codecs supporting variable bit-rate based on audio/speech input or having discontinuous transmission support must consider the issues discussed in Guidelines for the Use of Variable Bit Rate Audio with Secure RTP [RFC6562]. Suitable stock text for the security considerations section is provided in the template in the appendix. However, authors do need to actively consider any security issues from the start. Failure to address these issues may block approval and publication. ---- Next Section ---- A.13. Security Considerations [See Section 7.2] RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] , and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload formats responsibility to discuss or mandate what solutions are used to meet the basic security goals like confiedenitality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in Options for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. The rest of the this security consideration discusses the security impacting properties of the payload format itself. This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content. [The previous paragraph may need editing due to the format breaking either of the statements. Fill in here any further potential security threats created by the payload format itself.] Thanks Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnusn@gmail.com Sun Apr 14 23:22:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09FA21F85C4; Sun, 14 Apr 2013 23:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3bhWF53afOY; Sun, 14 Apr 2013 23:22:57 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EEFD621F8506; Sun, 14 Apr 2013 23:22:53 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id l13so595296wie.6 for ; Sun, 14 Apr 2013 23:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=oWTa94unAVy2NtXVbXbT4GpEtQ6CMTOrnUm3OUcFREM=; b=kM4mMVFGQ8vxPTfDgHrpWqu2OF+06gLJ3t4awhrboWjNiBr/0AQcwYU8J3VqEKiFWs yzAu2yPJbGgbJvoXz8IOq33tmerYRfYe3ibhudasA+Z0IRLYC2qmCeXuz9jYGj7Us0Gz 7CJYy3HvTwtUFSsjDSBRpoTuPz2WNGQsDBvXAYsG8Ycv5eXHkAidVoYAe+txjeMyVlBB 1RBsf6Tg4Vr136ft6hKUL54j4cO3tcSwUY+z0XhNLsodfa9bAEnY8paQ31TfOd+s4KKD Q343Fz9lloGOudWBwLVMTlNzBcv6IQpnouy7gIyb/EsQK4qGm6kpGjub7znvYpOzugfb VVQg== MIME-Version: 1.0 X-Received: by 10.180.188.141 with SMTP id ga13mr9638837wic.9.1366006973150; Sun, 14 Apr 2013 23:22:53 -0700 (PDT) Received: by 10.180.85.202 with HTTP; Sun, 14 Apr 2013 23:22:53 -0700 (PDT) Date: Sun, 14 Apr 2013 23:22:53 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "secdir@ietf.org" , draft-ietf-nfsv4-rfc3530bis-dot-x@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c37f5a6571e204da60488e Cc: "iesg@ietf.org" Subject: [secdir] Secdir review of draft-ietf-nfsv4-rfc3530bis-dot-x-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 06:22:57 -0000 --001a11c37f5a6571e204da60488e Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This NFSv4.0 document provides the XDR definition for NFSv4.0. As such, except for the introductory section and standard sections towards the end, it consists entirely of extractable, machine-readable declarations and definitions. The Security Considerations section simply refers to the rfc2530bis main document. This may be sufficient; however, if the NFSv4.0 XDR definition introduces any new parsing risks (for example, anything related to internationalization?), then it may be better placed in this document. -- Magnus --001a11c37f5a6571e204da60488e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have= reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. =A0These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This NFSv4.0 document provides the XDR definition for NFSv4.0. As such, exc= ept for the introductory section and standard sections towards the end, it = consists entirely of extractable, machine-readable declarations and definit= ions.

The Security Considerations section simply refers to the rfc2530bis main= document. This may be sufficient; however, if the NFSv4.0 XDR definition i= ntroduces any new parsing risks (for example, anything related to internati= onalization?), then it may be better placed in this document.

-- Magnus
--001a11c37f5a6571e204da60488e-- From yaronf.ietf@gmail.com Mon Apr 15 01:28:37 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6B521F8EB2; Mon, 15 Apr 2013 01:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.243 X-Spam-Level: X-Spam-Status: No, score=-97.243 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX+rZxtFUrxp; Mon, 15 Apr 2013 01:28:36 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7625D21F9309; Mon, 15 Apr 2013 01:28:35 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id o10so2107649eaj.37 for ; Mon, 15 Apr 2013 01:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uIZQP/SY6dk3CCdDZrR+RJXdkKJB1zruEpHAWIomfrc=; b=AXnsHvorhLg05S60TSNYKmoDDTiWS+o3+bTRfcXuC2y+YurmDA8eYYZFKuO66h0MJE M3hh8eXrb8j80eAqfAh75E1BAJLoOqUldDszCAd6o379bcw0enHEDwydK2bJGneVtdSN XVNSDeeqH4OZWIcR+hkR35cw3IGUIKJ3n5geMMszvGwJ9LzgdCYHKtds8vEuoHqTagrS h8OoU9L6ixbnR5N7ZCymgBrx0pS6CPFeMDuHMEzZ6FiPcEEkoxlY2hiD2WJlEbdi3wsc PIzD5czDl8w8vVTTZnsyR0QiYBCY3CnWGf0R9xXOb4Grubsx3lONhbg9YJY9hGt7xgwH eebg== X-Received: by 10.14.219.8 with SMTP id l8mr49657281eep.40.1366014514331; Mon, 15 Apr 2013 01:28:34 -0700 (PDT) Received: from [10.0.0.6] ([109.65.117.169]) by mx.google.com with ESMTPS id u44sm25543568eel.7.2013.04.15.01.28.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 01:28:33 -0700 (PDT) Message-ID: <516BBA2F.7080505@gmail.com> Date: Mon, 15 Apr 2013 11:28:31 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <5165D736.9010903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 08:28:37 -0000 Hi Iñaki, I apologize for my delayed response. Please see my comments below. I am still of the opinion that you should change the security "attitude" in the draft from descriptive (non-normative) to prescriptive. I also note below that leaving the security details essentially open also hurts the interoperability of the protocol. Thanks, Yaron On 2013-04-12 16:17, Iñaki Baz Castillo wrote: > Please let me one comment more about this at the end of this mail: > > > > 2013/4/11 Iñaki Baz Castillo : >> 2013/4/10 Yaron Sheffer : >> >>> Details >>> >>> RFC 3261 has 20 pages of security considerations, and defines >>> several security mechanisms. The current document "only" defines >>> a transport for SIP, but such transport needs to preserve the >>> security of any SIP mechanisms being used. In particular, it >>> should be clear how endpoint identities are determined at each >>> layer and how identities at different layers relate to one >>> another. In other words, what's known as "channel binding". >> >> IMHO there is no a "channel binding". It may be or not, that's up >> to the implementor. For example an implementor could use the same >> WS connection and carry SIP registrations and calls from different >> SIP accounts over the same WS connection. Another implementor may >> associate (at server side) each WS connection with a SIP identity >> (for example the SIP identity could be provided in a URL parameter >> in the WS HTTP GET request, or retrieved from a Cookie in the same >> HTTP request). >> >> Honestly I don't think we should force a specific behavior here. >> When SIP is transported over TCP there is no rules in RFC 3261 >> stating that the endpoint is associated to the TCP connection, same >> here IMHO. >> Channel binding only applies when the layers are both secure. So TCP is not interesting here, but TLS is. The second alternative you propose (using WS information to identify the SIP entity) raises some questions: what if I have logged in (to WS) as Yaron, but then I SIP-register or SIP-invite as Iñaki? Dealing with such issues requires a policy, and you need to at least mention it. Solving these issues securely probably requires more than policy, it requires actual binding between the layers (using some TLS-generated material when setting up the SIP connection). The easiest way out is to say that there's no authentication at the WS layer. But then you also lose confidentiality. >> >> >>> The only security-related section (other than the Security >>> Considerations) is Authentication (Sec. 7), and this section is >>> marked non-normative. So the reader is left to wonder: how is the >>> SIP client authenticated? How does this authentication relate to >>> the WebSocket-level client authentication? And similarly for the >>> server. >> >> IMHO we should leave this as flexible as possible. For example, as >> author of OverSIP (the first SIP proxy with WebSocket support) I >> leave the user to program it custom logic for >> authenticating/authorizing WebSocket connections and the SIP >> "layer" on top of them. From section "WebSocket >> authentication/authorization" at >> http://oversip.net/documentation/misc/sip_websocket/: >> >> >> ------------------------------------------------------------------ >> WebSocket authentication/authorization >> >> When a WebSocket client attempts to establish a WebSocket >> connection, OverSIP invokes user programmable callbacks. The user >> can there inspect parameters from the connection (including the >> HTTP GET request of the WebSocket handshake) in order to decide, >> based on any custom policy, whether to allow or deny the >> connection. >> >> The user can also assign custom parameters to the authorized >> WebSocket connection and retrieve such parameters when processing >> SIP requests coming through that WebSocket connection. By playing >> with these features several architectural solutions can be built >> for implementing any kind of authentication/authorization system. >> ------------------------------------------------------------------ This might work well for your implementation's target audience. But the RFC should allow implementers who are NOT security experts to build a secure implementation. I *think* most implementers of your draft will not be building open frameworks like your own implementation. They will be building actual UAs/servers that need to be secure. > > > About the above subject, I strongly consider that the draft MUST NOT > mandate how the implementor should authenticate/authorize WebSocket > connection/authentications or how he should correlate WebSocket > connections with SIP identities. If we mandate that then we are > limiting web developers. There are tons of ways in WWW world for > authenticating and authorizing connections/sessions, IMHO we should > not mandate nothing at the WebSocket layer because that is out of > the scope of the draft (which indeed just defines WebSocket as a new > transport for SIP, but does not attempt to deal with WebSocket > authentication/authorization). > > Please take into account that RFC 6455 (The WebSocket Protocol) does > NOT state how authentication/authorization in WebSocket sessions > should be implemented. Instead it leaves full flexibility to web > developers for choosing their preferred mechanism. Why should this > draft mandate that at *WebSocket* level? does RFC 3261 state > something about how a SIP proxy should accept or not SIP TCP > connections from certain IP addresses? > > The draft could mandate something like: > > "HTTP Digest authentication is required at WebSocket level when > establishing the WS handshake, and later HTTP Digest authentication > MUST be used for every SIP request over such a WS connection, and > both credentials must be the same and...". > > That would be a big error, and that would just work if we assume > that "SIP over WebSocket" is just valid for creating a pure phone in > a web (out of the context of the website itself) which would just > become a replacement for desktop phones or softphones. That's fully > wrong. There are a lot of possible scenarios for "SIP over > WebSocket": > > - A social network, which *already* has its > login/authentication/session/authorization mechanism, could include > SIP over WebSocket for enabling RTC between its users. No need for > Digest auth at all since the user was *already* logged in the web > site and thus the server(s) can correlate the HTTP session with the > WebSocket connection (via Cookies, a custom token or whatever). > > - Another web site could provide a "Web <--> PSTN" application in > which the user has to set his SIP information (SIP account, SIP > proxy, SIP password...). > > - etc etc > > > So, I strongly think that the draft is correct in this subject. > Mandating how authentication must be done would limit the scope of > this SIP transport and would make it 100% unusable for most of the > existing web deployments. I agree that it would be a mistake to mandate a specific auth mechanism for SIP or for WS. I think you should mandate that (any) such mechanism be used (and maybe give a few examples). And you should provide tools (like a header, a cookie format...) to build the correlation. Please also note that leaving these details open means that effectively, you will not have interoperability. You might want to consider mandating some minimal mechanisms so that you can have an interoperable *and* secure baseline. > > > Best regards. > > > > -- Iñaki Baz Castillo > From ibc@aliax.net Mon Apr 15 03:53:49 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7531E21F8689 for ; Mon, 15 Apr 2013 03:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MWj3dIZzWWw for ; Mon, 15 Apr 2013 03:53:48 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 20AE521F8411 for ; Mon, 15 Apr 2013 03:53:47 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id jy17so2570731qeb.39 for ; Mon, 15 Apr 2013 03:53:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=xCp4GdX5iFPlJuQj2KLqHCCYaREkhBzOTR4vt0Gwrdk=; b=QMPP0Cy6jzceUa44E1lXcvwl0I9SPnPfFgCN4UeVgjw2Jd8GZ9spa8OJYSHEHonVOz j+6tWjLmAZPrr1qxY6zi7IJBEWZjk8rIvekbDlLRzGl6jnMSBc72Y5bHsZWR/IzCR8Qw aCnmLR+OjmW0T8HmWp9AfZiNS5P3oMkRjaHBorj4yhRDwujBLqloOv6nUx8SZYRc1fEo XuN80CMGKNkWJTwlyVZ+uhz5C3Go7Uyd4ab3HF0RDDSn8xzkxcZQllV0xCRS7OqHrmg+ Usg0fMUnczDhg/FkWTw8gmn2KJsMLJWa11huouQhfdbTSo4WEAFkGovACug9wwBXW8EY bErw== X-Received: by 10.224.53.11 with SMTP id k11mr21827859qag.3.1366023227270; Mon, 15 Apr 2013 03:53:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Mon, 15 Apr 2013 03:53:26 -0700 (PDT) In-Reply-To: <516BBA2F.7080505@gmail.com> References: <5165D736.9010903@gmail.com> <516BBA2F.7080505@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 15 Apr 2013 12:53:26 +0200 Message-ID: To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkX13jvehm5q5fQVvGZ7Ll98/3T1xG1DE1oX2ors+o6MYcXqst/n1hMQvNF2KOCw+i5RKq0 Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:53:49 -0000 2013/4/15 Yaron Sheffer : > Hi I=C3=B1aki, > > I apologize for my delayed response. Please see my comments below. I am > still of the opinion that you should change the security "attitude" in > the draft from descriptive (non-normative) to prescriptive. > > I also note below that leaving the security details essentially open also > hurts the interoperability of the protocol. Hi Yaron, thanks a lot for your detailed response. Before inline replies please let me expose some examples of SIP over WebSocket: Case 1) This is a real case: Asterisk PBX also implements SIP WebSocket transport. This implementation is 100% website agnostic as it just requires the SIP WS client to connect to Asterisk IP and port 8088 (or the TLS version) and set "/ws" in the URL of the WebSocket HTTP GET request handshake. It does not care at all about the website domain/origin in which the JavaScript SIP WebSocket client is running. And finally Asterisk requires SIP Digest authentication for any SIP request coming over WebSocket connections (unless the "peer" has been configured with "insecure=3Dinvite,port" per local policy). This is obvisouly the simplest usecase in which Web / WebSocket stuff is irrelevant for the proxy/PBX, which just exposes a WebSocket interface but does not care about web logins, web sessions or whatever WWW related stuff. Case 2) A telco PSTN provider may offer a website in which its clients login with some web user account. The provider does not want to expose the client's SIP password in the web for security/privacy reasons. Once the user is logged, the Web server returns a Cookie containing a SIP identity and a session token string to the JavaScript application. The JS app opens then a WebSocket connection to a SIP WebSocket server by attaching the Cookie in the WebSocket HTTP handshake request. The SIP WebSocket server inspects the session token in the Cookie and retrieves from a database the SIP identity such a web session is associated to. The SIP WebSocket server requires that any SIP request coming from that WebSocket connection has a From header containing such a SIP identity. Otherwise it rejects the request and, optionally, closes the WebSocket connection (as it seems there is a CLI spoof attempt). Case 3) Same as case 2, but in this case the WebSocket URI has a domain/subdomain which does not match the domain of the Web server from which the WS SIP client has been retrieved and, thus, the usage of Cookies is not allowed. In this case the Web server returns some kind of session token string after the user performs the web login procedure. The WS SIP JavaScript app makes the WebSocket connection by adding such a session token string as a SESSION_TOKEN query parameter value in the WebSocket GET request. The SIP WebSocket server reads it and looks for its value in a DB in which the Web server stored each session token and the user profile it belongs to. Case 4) Some as case 2 or case 3, but the SIP WebSocket server will also request SIP Digest authentication from every request. Considering the above four examples, let me please reply inline to your comments: >> 2013/4/11 I=C3=B1aki Baz Castillo : >>> IMHO there is no a "channel binding". It may be or not, that's up >>> to the implementor. For example an implementor could use the same >>> WS connection and carry SIP registrations and calls from different >>> SIP accounts over the same WS connection. Another implementor may >>> associate (at server side) each WS connection with a SIP identity >>> (for example the SIP identity could be provided in a URL parameter >>> in the WS HTTP GET request, or retrieved from a Cookie in the same >>> HTTP request). > The second alternative you propose > (using WS information to identify the SIP entity) raises some questions: > what if I have logged in (to WS) as Yaron, but then I SIP-register or > SIP-invite as I=C3=B1aki? In case 1 above, this does not apply since there is no Web/WS login. In cases 2 and 3, the SIP WebSocket server would reject the SIP REGISTER since the SIP AoR being registered does not match the SIP identity associated to this WebSocket connection. In case 4 the SIP WebSocket could also reject the REGISTER, or may be not since auth at SIP level will be also requiered by the server. > Dealing with such issues requires a policy, and you > need to at least mention it. The problem I see is: how to mention a policy that cannot be applied for every case? As said above, case 1 does not deal at all with Web/WebSocket login/session stuff. > Solving these issues securely probably > requires more than policy, it requires actual binding between the layers > (using some TLS-generated material when setting up the SIP connection). Let me please address the above subject without adding TLS. This is, let's assume non secure WebSocket connections for the four cases above. Do you agree that it is not possible to mention a policy due the differences between the use cases? Of course the draft may mention more deeply the different authentication/authorization scenarios, but I cannot imagine a policy with a MUST since some of the above 4 scenarios would be invalidated. >>> ------------------------------------------------------------------ >>> WebSocket authentication/authorization >>> >>> When a WebSocket client attempts to establish a WebSocket >>> connection, OverSIP invokes user programmable callbacks. The user >>> can there inspect parameters from the connection (including the >>> HTTP GET request of the WebSocket handshake) in order to decide, >>> based on any custom policy, whether to allow or deny the >>> connection. >>> >>> The user can also assign custom parameters to the authorized >>> WebSocket connection and retrieve such parameters when processing >>> SIP requests coming through that WebSocket connection. By playing >>> with these features several architectural solutions can be built >>> for implementing any kind of authentication/authorization system. >>> ------------------------------------------------------------------ > > > This might work well for your implementation's target audience. But the > RFC should allow implementers who are NOT security experts to build a sec= ure > implementation. I *think* most implementers of your draft will not be > building open frameworks like your own implementation. They will be build= ing > actual UAs/servers that need to be secure. I understand your concerns but, which kind of policy could the draft mandate without invalidating some of the use cases above? What about if the draft mandates "some" kind of authentication? For example= : "If SIP Digest authentication is not requestes, then the SIP WebSocket server MUST authorize SIP requests based on a previous Web or WebSocket login / authentication procedure, and MUST validate the SIP identity in SIP requests by matching it with the SIP identity associated to the WebSocket session. If no authentication is done at WebSocket level then SIP Digest authentication is required for every SIP requests coming from the WebSocket connection." >> So, I strongly think that the draft is correct in this subject. >> Mandating how authentication must be done would limit the scope of >> this SIP transport and would make it 100% unusable for most of the >> existing web deployments. > > > I agree that it would be a mistake to mandate a specific auth mechanism f= or > SIP or for WS. I think you should mandate that (any) such mechanism be us= ed > (and maybe give a few examples). And you should provide tools (like a > header, a cookie format...) to build the correlation. Ok, that would be indeed an useful improvement for the draft. So please let me suggest the following sections / changes in the draft to satisfy this need: - Some kind of non-normative new section called "Use Cases" in which something like the above four examples would be mentioned. - Changes to the "Authentication" section which would become normative and would mandate "some kind of authentication", may be in WS layer and/or SIP layer, and would also mandate some kind of "authorization/validation" of SIP requests in case the authentication was done at WS layer. - A new subsection under "Authentication" section called "Client TLS Authentication": If the SIP WS Client provides a valid TLS certificate during the WS handshake (and the SIP WebSocket server alows client authentication based on TLS certificates) then the server may inspect the SIP identity in such a certificate and then require that SIP requests from that WS connection MUST contain such a SIP identity (otherwise the server could choose whether to just reject the request with 403, or request SIP Diget authentication, or close the WS connection). > Please also note that leaving these details open means that effectively, = you > will not have interoperability. You might want to consider mandating some > minimal mechanisms so that you can have an interoperable *and* secure > baseline. IMHO we cannot mandate how Web developers must implement login procedures in their websites. There are tons of mechanisms for that purpose, and it should be possible that all those mechanisms can be reused when adding SIP over WebSocket capabilities to a website. When we talk about "interoperability" and "SIP over WebSocket" I think we should consider that: - WebSite developers build the WWW server side (the Web server and logic) along with the client side (the HTML and the JavaScript app to be executed in the browser). Typically a JS app (I'm not talking about a JS library) is just designed to run against a specific web site (the JS code is custom per web site). - Web / WebSocket authentication can be done in tons of ways. Mandating a specific one would break existing scenarios. - A SIP WS library (i.e. JsSIP or SipML5) should be flexible enough to allow setting any URL path and custom URL params in the WS handshake request, and MUST implement SIP Digest. Then the web developer would integrate such a library within his website and would choose the auth mechanism he prefers. - By satisfying this previous point, and SIP WebSocket client could interoperate with any SIP WebSocket server that does not require Web/WebSocket authentication (case 1 above). When Web/WebSocket login is also required then we cannot mandate "interoperability" since it is up to the website developer how to implement the authentication procedure, which means that the SIP WS JavaScript app should be integrated into such a aspecific website by the web developer responsible of that web site. If there was agreement in these previous considerations, is it ok if I performs the additions and changes in the draft exposed in a previous paragraph of this mail? Thanks a lot for all. > > >> >> >> Best regards. >> >> >> >> -- I=C3=B1aki Baz Castillo >> > -- I=C3=B1aki Baz Castillo From yaronf.ietf@gmail.com Mon Apr 15 08:05:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C7121F93CC; Mon, 15 Apr 2013 08:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.543 X-Spam-Level: X-Spam-Status: No, score=-98.543 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu+EFRvMJGBH; Mon, 15 Apr 2013 08:05:58 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9704B21F93F0; Mon, 15 Apr 2013 08:05:57 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id z7so2324467eaf.31 for ; Mon, 15 Apr 2013 08:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Mxvo/dYs3AWgmLhbNG7RqGwvItClHjtvdjkjVNQWvl4=; b=YG/upJsVjRYw+45UAbbSgMrbTYbaJVYNRm3kvzWW1QjhxR/IZT0Lx886saklqoKyUI Nk3P2sLH4sWPoUhqrVlSBGYNxbVkfspZ+sKquO1/4mTWjWM62QSwOfQFnr3gQwoO+Nvl GDvUCOzXVVao3X5900MNsy2F/pzGLV4DQwQBIucAdDOGtSaMobzzarFOpNWZcrQyZxy6 vFUzNaue5S1XrNhncl79GTuyakQxIdhBcfx5PjTzpmp/RBzI6wcQBp6NWx+dYc06LqnZ 3OFWF1hTakJUSvHWG3smloVNBQXlQa8F7Zug5hnkkHD5crYVSgrzglBwSB/6Son333yj s7VQ== X-Received: by 10.15.75.70 with SMTP id k46mr17458606eey.4.1366038356561; Mon, 15 Apr 2013 08:05:56 -0700 (PDT) Received: from [10.0.0.6] ([109.65.117.169]) by mx.google.com with ESMTPS id ch6sm10479118eeb.17.2013.04.15.08.05.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 08:05:55 -0700 (PDT) Message-ID: <516C1750.90505@gmail.com> Date: Mon, 15 Apr 2013 18:05:52 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <5165D736.9010903@gmail.com> <516BBA2F.7080505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:05:59 -0000 Hi again, Yes, I agree with your plan for moving forward. A few remaining comments: - Unless I missed something, you only talked about authentication of the client, and did not mention authentication of the server to the client. From the point of view of the client (and customer?) this is just as important. - Unfortunately we rarely have usable client auth with TLS. I wish we had something better than client certificates. In fact there are some implementations of RFC 5054 out there, and it would be great if you could accommodate them as well. - I would advise you take the draft back to the WG to have these changes more thoroughly reviewed. I would be more than happy to review the new draft, too. Thanks, Yaron On 2013-04-15 13:53, Iñaki Baz Castillo wrote: > 2013/4/15 Yaron Sheffer : >> Hi Iñaki, >> >> I apologize for my delayed response. Please see my comments below. I am >> still of the opinion that you should change the security "attitude" in >> the draft from descriptive (non-normative) to prescriptive. >> >> I also note below that leaving the security details essentially open also >> hurts the interoperability of the protocol. > > > Hi Yaron, thanks a lot for your detailed response. Before inline > replies please let me expose some examples of SIP over WebSocket: > > > Case 1) > > This is a real case: Asterisk PBX also implements SIP WebSocket > transport. This implementation is 100% website agnostic as it just > requires the SIP WS client to connect to Asterisk IP and port 8088 (or > the TLS version) and set "/ws" in the URL of the WebSocket HTTP GET > request handshake. It does not care at all about the website > domain/origin in which the JavaScript SIP WebSocket client is running. > And finally Asterisk requires SIP Digest authentication for any SIP > request coming over WebSocket connections (unless the "peer" has been > configured with "insecure=invite,port" per local policy). > > This is obvisouly the simplest usecase in which Web / WebSocket stuff > is irrelevant for the proxy/PBX, which just exposes a WebSocket > interface but does not care about web logins, web sessions or whatever > WWW related stuff. > > > Case 2) > > A telco PSTN provider may offer a website in which its clients login > with some web user account. The provider does not want to expose the > client's SIP password in the web for security/privacy reasons. Once > the user is logged, the Web server returns a Cookie containing a SIP > identity and a session token string to the JavaScript application. The > JS app opens then a WebSocket connection to a SIP WebSocket server by > attaching the Cookie in the WebSocket HTTP handshake request. The SIP > WebSocket server inspects the session token in the Cookie and > retrieves from a database the SIP identity such a web session is > associated to. The SIP WebSocket server requires that any SIP request > coming from that WebSocket connection has a From header containing > such a SIP identity. Otherwise it rejects the request and, optionally, > closes the WebSocket connection (as it seems there is a CLI spoof > attempt). > > > Case 3) > > Same as case 2, but in this case the WebSocket URI has a > domain/subdomain which does not match the domain of the Web server > from which the WS SIP client has been retrieved and, thus, the usage > of Cookies is not allowed. In this case the Web server returns some > kind of session token string after the user performs the web login > procedure. The WS SIP JavaScript app makes the WebSocket connection by > adding such a session token string as a SESSION_TOKEN query parameter > value in the WebSocket GET request. The SIP WebSocket server reads it > and looks for its value in a DB in which the Web server stored each > session token and the user profile it belongs to. > > > > Case 4) > > Some as case 2 or case 3, but the SIP WebSocket server will also > request SIP Digest authentication from every request. > > > > Considering the above four examples, let me please reply inline to > your comments: > > > > > >>> 2013/4/11 Iñaki Baz Castillo : > >>>> IMHO there is no a "channel binding". It may be or not, that's up >>>> to the implementor. For example an implementor could use the same >>>> WS connection and carry SIP registrations and calls from different >>>> SIP accounts over the same WS connection. Another implementor may >>>> associate (at server side) each WS connection with a SIP identity >>>> (for example the SIP identity could be provided in a URL parameter >>>> in the WS HTTP GET request, or retrieved from a Cookie in the same >>>> HTTP request). > > >> The second alternative you propose >> (using WS information to identify the SIP entity) raises some questions: > >> what if I have logged in (to WS) as Yaron, but then I SIP-register or >> SIP-invite as Iñaki? > > In case 1 above, this does not apply since there is no Web/WS login. > > In cases 2 and 3, the SIP WebSocket server would reject the SIP > REGISTER since the SIP AoR being registered does not match the SIP > identity associated to this WebSocket connection. > > In case 4 the SIP WebSocket could also reject the REGISTER, or may be > not since auth at SIP level will be also requiered by the server. > > > > > >> Dealing with such issues requires a policy, and you >> need to at least mention it. > > The problem I see is: how to mention a policy that cannot be applied > for every case? As said above, case 1 does not deal at all with > Web/WebSocket login/session stuff. > > > >> Solving these issues securely probably >> requires more than policy, it requires actual binding between the layers >> (using some TLS-generated material when setting up the SIP connection). > > Let me please address the above subject without adding TLS. This is, > let's assume non secure WebSocket connections for the four cases > above. Do you agree that it is not possible to mention a policy due > the differences between the use cases? Of course the draft may mention > more deeply the different authentication/authorization scenarios, but > I cannot imagine a policy with a MUST since some of the above 4 > scenarios would be invalidated. > > > > > >>>> ------------------------------------------------------------------ >>>> WebSocket authentication/authorization >>>> >>>> When a WebSocket client attempts to establish a WebSocket >>>> connection, OverSIP invokes user programmable callbacks. The user >>>> can there inspect parameters from the connection (including the >>>> HTTP GET request of the WebSocket handshake) in order to decide, >>>> based on any custom policy, whether to allow or deny the >>>> connection. >>>> >>>> The user can also assign custom parameters to the authorized >>>> WebSocket connection and retrieve such parameters when processing >>>> SIP requests coming through that WebSocket connection. By playing >>>> with these features several architectural solutions can be built >>>> for implementing any kind of authentication/authorization system. >>>> ------------------------------------------------------------------ >> >> >> This might work well for your implementation's target audience. But the >> RFC should allow implementers who are NOT security experts to build a secure >> implementation. I *think* most implementers of your draft will not be >> building open frameworks like your own implementation. They will be building >> actual UAs/servers that need to be secure. > > > I understand your concerns but, which kind of policy could the draft > mandate without invalidating some of the use cases above? > > What about if the draft mandates "some" kind of authentication? For example: > > > > "If SIP Digest authentication is not requestes, then the SIP WebSocket > server MUST authorize SIP requests based on a previous Web or > WebSocket login / authentication procedure, and MUST validate the SIP > identity in SIP requests by matching it with the SIP identity > associated to the WebSocket session. If no authentication is done at > WebSocket level then SIP Digest authentication is required for every > SIP requests coming from the WebSocket connection." > > > > > >>> So, I strongly think that the draft is correct in this subject. >>> Mandating how authentication must be done would limit the scope of >>> this SIP transport and would make it 100% unusable for most of the >>> existing web deployments. >> >> >> I agree that it would be a mistake to mandate a specific auth mechanism for >> SIP or for WS. I think you should mandate that (any) such mechanism be used >> (and maybe give a few examples). And you should provide tools (like a >> header, a cookie format...) to build the correlation. > > Ok, that would be indeed an useful improvement for the draft. So > please let me suggest the following sections / changes in the draft to > satisfy this need: > > > - Some kind of non-normative new section called "Use Cases" in which > something like the above four examples would be mentioned. > > - Changes to the "Authentication" section which would become normative > and would mandate "some kind of authentication", may be in WS layer > and/or SIP layer, and would also mandate some kind of > "authorization/validation" of SIP requests in case the authentication > was done at WS layer. > > - A new subsection under "Authentication" section called "Client TLS > Authentication": If the SIP WS Client provides a valid TLS certificate > during the WS handshake (and the SIP WebSocket server alows client > authentication based on TLS certificates) then the server may inspect > the SIP identity in such a certificate and then require that SIP > requests from that WS connection MUST contain such a SIP identity > (otherwise the server could choose whether to just reject the request > with 403, or request SIP Diget authentication, or close the WS > connection). > > > > > >> Please also note that leaving these details open means that effectively, you >> will not have interoperability. You might want to consider mandating some >> minimal mechanisms so that you can have an interoperable *and* secure >> baseline. > > IMHO we cannot mandate how Web developers must implement login > procedures in their websites. There are tons of mechanisms for that > purpose, and it should be possible that all those mechanisms can be > reused when adding SIP over WebSocket capabilities to a website. > > When we talk about "interoperability" and "SIP over WebSocket" I think > we should consider that: > > - WebSite developers build the WWW server side (the Web server and > logic) along with the client side (the HTML and the JavaScript app to > be executed in the browser). Typically a JS app (I'm not talking about > a JS library) is just designed to run against a specific web site (the > JS code is custom per web site). > > - Web / WebSocket authentication can be done in tons of ways. > Mandating a specific one would break existing scenarios. > > - A SIP WS library (i.e. JsSIP or SipML5) should be flexible enough to > allow setting any URL path and custom URL params in the WS handshake > request, and MUST implement SIP Digest. Then the web developer would > integrate such a library within his website and would choose the auth > mechanism he prefers. > > - By satisfying this previous point, and SIP WebSocket client could > interoperate with any SIP WebSocket server that does not require > Web/WebSocket authentication (case 1 above). When Web/WebSocket login > is also required then we cannot mandate "interoperability" since it is > up to the website developer how to implement the authentication > procedure, which means that the SIP WS JavaScript app should be > integrated into such a aspecific website by the web developer > responsible of that web site. > > > If there was agreement in these previous considerations, is it ok if I > performs the additions and changes in the draft exposed in a previous > paragraph of this mail? > > > > Thanks a lot for all. > > > > > > >> >> >>> >>> >>> Best regards. >>> >>> >>> >>> -- Iñaki Baz Castillo >>> >> > > > > -- > Iñaki Baz Castillo > > From ibc@aliax.net Mon Apr 15 08:39:05 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0121F93EE for ; Mon, 15 Apr 2013 08:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J-zcPWzIuZu for ; Mon, 15 Apr 2013 08:39:04 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id B901E21F93E9 for ; Mon, 15 Apr 2013 08:39:04 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id 6so2743284qeb.22 for ; Mon, 15 Apr 2013 08:39:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=FujVlplovB6uzvAyUbOD+r9Y3UPVVzUnPQ/4Q0JB5ss=; b=pKYVjZsSotXRMV352zq43PC9JVZuCqm7UGp/8wuntEGieXhP9xkSuk2LPZYq7mBJCp Kh0xRYAlHR55+zhEnX4HBAo2dWxRR3qRSMpJQdVhSy+PcbDywl3SRWSf6EvBcEfAdu2X xEpYGCOA9NrDtcQGFpgrH3lDtvK1dUUvq2kL2NjUDMKO0ikEz5thhy3ygdGHh1vWoa+w 1rX8iTMy2VLZS1TVgna9rczxwYkzmUqUv/ASBXcHjaY3x2NpNlcwscL6s7tyzX3M8KHS zAGBghjWauSNkxl7kbHGc9PlD7kMAgCu2U/VPHg5hR1/0rkcXMRIArhgYHA95Z5nKYpX aHLw== X-Received: by 10.224.53.11 with SMTP id k11mr23005299qag.3.1366040344204; Mon, 15 Apr 2013 08:39:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Mon, 15 Apr 2013 08:38:43 -0700 (PDT) In-Reply-To: <516C1750.90505@gmail.com> References: <5165D736.9010903@gmail.com> <516BBA2F.7080505@gmail.com> <516C1750.90505@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 15 Apr 2013 17:38:43 +0200 Message-ID: To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmM5nDcaaBXncKHM0+Xwu/QMhBpRp30WFMCbg9X5aiXJ4nyO0XsCS0m7yRA8VXj2bbbHjbD Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:39:05 -0000 2013/4/15 Yaron Sheffer : > Hi again, > > Yes, I agree with your plan for moving forward. A few remaining comments: > > - Unless I missed something, you only talked about authentication of the > client, and did not mention authentication of the server to the client. F= rom > the point of view of the client (and customer?) this is just as important= . Nothing prevents a SIP WebSocket client to request authentication for an incoming request. Is it OK if the draft also mentions it in the appropriate section? > - Unfortunately we rarely have usable client auth with TLS. I wish we had > something better than client certificates. In fact there are some > implementations of RFC 5054 out there, and it would be great if you could > accommodate them as well. Great. Would it be ok by mentioning such a security mechanism it in the Security section? > - I would advise you take the draft back to the WG to have these changes > more thoroughly reviewed. I would be more than happy to review the new > draft, too. Thanks a lot. We will publish a new revision with the requested improvement= s. -- I=C3=B1aki Baz Castillo From yaronf.ietf@gmail.com Mon Apr 15 08:42:25 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF4F21F941D; Mon, 15 Apr 2013 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.193 X-Spam-Level: X-Spam-Status: No, score=-99.193 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgFPpzAR8mRv; Mon, 15 Apr 2013 08:42:24 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id F402821F941A; Mon, 15 Apr 2013 08:42:22 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h10so2229975eaj.7 for ; Mon, 15 Apr 2013 08:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Dh+5/o7HolePmLdoZognKVpY4l2p4tJplkVNKSasH8I=; b=WzGMPUfXcn5DPNz2xuU7c/m5fiDipjo6XnPCeMTkvY5UoZmHjJbi9TAPUHEP7eH5nd TwoEO+/YP0+fzl0lTWkxZ0Zo7xTHRLl8jXS6eMntDaz7WkaRhGA455/fWJh1GmQURFzz oJawIxshPRU3YIr0ex30J/GVyWF7pjDfDMoLIL6XZZdLCygCPEpZUE4lJ82HX5kBoFqz aWq0F8J2229fSynzKJNnbAzeBqWJtPbCbaIHvLbSxHIEmTbBExdE9DiJD71P1a6w3onT b7f1WxOcEwTzoJDVgNkqc16FELE0aYdgQZdBtg5gr96njUeiUQa5O7loSFxLvV71RA/P Bq7w== X-Received: by 10.14.219.130 with SMTP id m2mr8188845eep.32.1366040539160; Mon, 15 Apr 2013 08:42:19 -0700 (PDT) Received: from [10.0.0.6] ([109.65.117.169]) by mx.google.com with ESMTPS id b47sm7948470eez.2.2013.04.15.08.42.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 08:42:17 -0700 (PDT) Message-ID: <516C1FD7.2030402@gmail.com> Date: Mon, 15 Apr 2013 18:42:15 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <5165D736.9010903@gmail.com> <516BBA2F.7080505@gmail.com> <516C1750.90505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:42:25 -0000 Authentication of incoming requests is important, but I was talking about something else: how does the client know that it is talking to the right server, e.g. when performing registration (I do hope there's a secure way to do it). Best, Yaron On 2013-04-15 18:38, Iñaki Baz Castillo wrote: > 2013/4/15 Yaron Sheffer : >> Hi again, >> >> Yes, I agree with your plan for moving forward. A few remaining comments: >> >> - Unless I missed something, you only talked about authentication of the >> client, and did not mention authentication of the server to the client. From >> the point of view of the client (and customer?) this is just as important. > > Nothing prevents a SIP WebSocket client to request authentication for > an incoming request. Is it OK if the draft also mentions it in the > appropriate section? > > > >> - Unfortunately we rarely have usable client auth with TLS. I wish we had >> something better than client certificates. In fact there are some >> implementations of RFC 5054 out there, and it would be great if you could >> accommodate them as well. > > Great. Would it be ok by mentioning such a security mechanism it in > the Security section? > > > >> - I would advise you take the draft back to the WG to have these changes >> more thoroughly reviewed. I would be more than happy to review the new >> draft, too. > > Thanks a lot. We will publish a new revision with the requested improvements. > > > > -- > Iñaki Baz Castillo > > From ibc@aliax.net Mon Apr 15 08:49:36 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C66621F940A for ; Mon, 15 Apr 2013 08:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esdhAwTLq6DH for ; Mon, 15 Apr 2013 08:49:36 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 99BE921F940D for ; Mon, 15 Apr 2013 08:49:35 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id b40so358011qcq.11 for ; Mon, 15 Apr 2013 08:49:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=FGwCXStMnJpRv7+OP8ftjM/5s65E+FrMqq3EGIqMoBQ=; b=f+GRf/lZr43aseOi3QCm7/vn07CgYt6U+E7TzLGRmDmvPV44V53XQmrGsybDmVuBwJ roXc/mIaPPh6H8EMNnorHcLf9rCAsiTaPIoXJCAKDB7u9rjmZFCMVgMNXpW08Bwz3V6d d46uXkL6OxkPFk6WE1OZKbZWpVTslTOxgiKVEiJbFEW3oATsDkuurbJdkWQyl5EDCEhu fHVYqK09AjFNiRCqaBw+PRBtNKjDcTbNkLM1fNWlqn1trc65CvQOCILYNOD1Rl0Gd/1N 7p3OdKtnK6osRnJxPvBQi1Fx19TrhIvqYHPDiYmqNqihRzcBNubwmoskDM92ClZyPq4Q jIJA== X-Received: by 10.49.104.196 with SMTP id gg4mr26666246qeb.53.1366040975058; Mon, 15 Apr 2013 08:49:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Mon, 15 Apr 2013 08:49:15 -0700 (PDT) In-Reply-To: <516C1FD7.2030402@gmail.com> References: <5165D736.9010903@gmail.com> <516BBA2F.7080505@gmail.com> <516C1750.90505@gmail.com> <516C1FD7.2030402@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 15 Apr 2013 17:49:15 +0200 Message-ID: To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkyqGKIA+Nu5rmku9EfkMo/CzfZRzLU9TPJOC1cgz+uj6lvMy44mo5HykMgs35HYwllMRd2 Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:49:36 -0000 2013/4/15 Yaron Sheffer : > Authentication of incoming requests is important, but I was talking about > something else: how does the client know that it is talking to the right > server, e.g. when performing registration (I do hope there's a secure way= to > do it). Hi Yaron, let me a question please: No one RFC describing a SIP transport (i.e. RFC 4168 "SIP SCTP Transport") talks about this subject. May be I'm wrong but AFAIK this it not related to the WebSocket layer but to the SIP layer, so it should be defined for any transport in a separate document (of course I may miss something). Said in other words: how does a SIP TCP client know that it is talking to the right server when performing SIP registration? RFC 3261 says nothing about it. If such a security consideration should be defined, why should it defined just for SIP over WebSocket? Thanks a lot. -- I=C3=B1aki Baz Castillo From yaronf.ietf@gmail.com Mon Apr 15 08:52:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73C121F940B; Mon, 15 Apr 2013 08:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.138 X-Spam-Level: X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[AWL=2.161, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2L9Aqsehc5P; Mon, 15 Apr 2013 08:52:29 -0700 (PDT) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id BC7DE21F9305; Mon, 15 Apr 2013 08:52:28 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id l10so2287701eei.8 for ; Mon, 15 Apr 2013 08:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G5605tsQCuHIG+kn6QKWVTdrH8ejyIF98tM/4uCvlvo=; b=WbJopwG0tIMD+gEprpgEKk6nQ27MOz51B1BJq6gvNXnXrSVWHbLBJHs/xy7aYh1lfW MM+7r3dXdMcL0TU7zu7NpVCRVmNGZWRGajqhjNIkb3BPYhU0Xf46RP+UMlLMeHdjepRF v+IfpZ022qmKbHY9fcT10um5898d75u7b7tywq5WMSKBsOGobs2huit94OBABxHM2XMJ 1hsAmYDoWOUTJsnMVZk5Ga+QY2sMGD/C72gSyMcbLM7KU34YWF1Xaa3xG2nAZz+tE0bL oIWnIR1+7WH+6pAO4rNiNtfKcNvqm5TiJ5e/1KQkdkNX3jnIOmxxtdBH4LswoVoLYzIK xppA== X-Received: by 10.15.83.73 with SMTP id b49mr63203238eez.25.1366041147836; Mon, 15 Apr 2013 08:52:27 -0700 (PDT) Received: from [10.0.0.6] ([109.65.117.169]) by mx.google.com with ESMTPS id b5sm27441902eew.16.2013.04.15.08.52.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 08:52:27 -0700 (PDT) Message-ID: <516C2238.5000200@gmail.com> Date: Mon, 15 Apr 2013 18:52:24 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <5165D736.9010903@gmail.com> <516BBA2F.7080505@gmail.com> <516C1750.90505@gmail.com> <516C1FD7.2030402@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:52:29 -0000 I feared as much. If this is not defined for SIP, then I agree it should not be defined just for WebSocket. But maybe it's time the SIP community did something about it. Thanks, Yaron On 2013-04-15 18:49, Iñaki Baz Castillo wrote: > 2013/4/15 Yaron Sheffer : >> Authentication of incoming requests is important, but I was talking about >> something else: how does the client know that it is talking to the right >> server, e.g. when performing registration (I do hope there's a secure way to >> do it). > > Hi Yaron, let me a question please: > > No one RFC describing a SIP transport (i.e. RFC 4168 "SIP SCTP > Transport") talks about this subject. May be I'm wrong but AFAIK this > it not related to the WebSocket layer but to the SIP layer, so it > should be defined for any transport in a separate document (of course > I may miss something). > > Said in other words: how does a SIP TCP client know that it is talking > to the right server when performing SIP registration? RFC 3261 says > nothing about it. If such a security consideration should be defined, > why should it defined just for SIP over WebSocket? > > Thanks a lot. > > > -- > Iñaki Baz Castillo > > From pkyzivat@alum.mit.edu Mon Apr 15 10:06:47 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECB121F9610 for ; Mon, 15 Apr 2013 10:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04tYEzf10QF8 for ; Mon, 15 Apr 2013 10:06:46 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 95D4021F960C for ; Mon, 15 Apr 2013 10:06:46 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta05.westchester.pa.mail.comcast.net with comcast id QAu91l0030SCNGk55H6mHE; Mon, 15 Apr 2013 17:06:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id QH6l1l00i3ZTu2S3VH6laz; Mon, 15 Apr 2013 17:06:46 +0000 Message-ID: <516C33A5.3050301@alum.mit.edu> Date: Mon, 15 Apr 2013 13:06:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yaron Sheffer References: <5165D736.9010903@gmail.com> <516BBA2F.7080505@gmail.com> <516C1750.90505@gmail.com> <516C1FD7.2030402@gmail.com> <516C2238.5000200@gmail.com> In-Reply-To: <516C2238.5000200@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366045606; bh=ew+DRDsA2uzMFsQq/ptDk4UwXFzH3WoyOIlaCEw8Myw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=r5PnDKXMf4V5A/9GErupqPbI0cF0FSUK9AwgF6XJlVzE4HcgrwAj4oCyWJpHDx4IE 9gC5Klz3J6CRuwyM+OYd6PH1953+ag9GBPMeKq3yDW9s8EXSSITJFWW/eqF19/VfR0 CFJ8K6qex+1W9xCf1Edl2yx69uXwoNLpktzsF50IEbkS2Mx8ZGZPQaDvGXTI/DAzMn g5UCMWLoAGk32ooWVXJOC6/k54rzZO+c60bkoI2EZ+VMwkR5jIxIh0BEI7QKelhYow wpSyGr0NTT4AX6N+64AkKbTZk6/y/89MgylIYqxZyHwzULDKkwznK+MVkOjJ9OJlGf obV0fZcNvydnA== X-Mailman-Approved-At: Mon, 15 Apr 2013 10:14:19 -0700 Cc: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:06:47 -0000 Yaron, On 4/15/13 11:52 AM, Yaron Sheffer wrote: > I feared as much. If this is not defined for SIP, then I agree it should > not be defined just for WebSocket. It is a difficult subject in sip, without perfect solutions. Part of the problem is that calls are often forwarded. And much of sip is based on transitive trust. There is one mechanism that does address this: RFC4916. It is driven by a request in the reverse direction of the call. So it can be authenticated using any of the sip mechanisms for authenticating the sender of requests. > But maybe it's time the SIP community did something about it. The above is one of the things we did. The original authentication mechanisms in 3261 were found inadequate, and others have been added. Of note is RFC4474, but AFAIK it has had very limited deployment. RFC3325 is deployed a lot as part of 3gpp, though it puts a lot of trust in the infrastructure. All of these things may be used over the websocket transport. Thanks, Paul (sipcore co-chair) > > Thanks, > Yaron > > On 2013-04-15 18:49, Iñaki Baz Castillo wrote: >> 2013/4/15 Yaron Sheffer : >>> Authentication of incoming requests is important, but I was talking >>> about >>> something else: how does the client know that it is talking to the right >>> server, e.g. when performing registration (I do hope there's a secure >>> way to >>> do it). >> >> Hi Yaron, let me a question please: >> >> No one RFC describing a SIP transport (i.e. RFC 4168 "SIP SCTP >> Transport") talks about this subject. May be I'm wrong but AFAIK this >> it not related to the WebSocket layer but to the SIP layer, so it >> should be defined for any transport in a separate document (of course >> I may miss something). >> >> Said in other words: how does a SIP TCP client know that it is talking >> to the right server when performing SIP registration? RFC 3261 says >> nothing about it. If such a security consideration should be defined, >> why should it defined just for SIP over WebSocket? >> >> Thanks a lot. >> >> >> -- >> Iñaki Baz Castillo >> >> > From new-work-bounces@ietf.org Mon Apr 15 18:16:03 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A1A21E8037; Mon, 15 Apr 2013 18:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1366074963; bh=wHZw7C5J+FAa7zyUFR3JMXTg564LI0c8hz1tsVBzkes=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=QvCef+v1GsjXNuMssMh7qyNZqx8LQ/rD83TxQC4pkU8a4iyC59f/e4cChMG/7F9g3 CyXmtSSTmcNJMWT5jhb+hIJiLdD3VGUWhvg5nW4CbM9IxD2ODuLxrMGNwC7rVk6XTa dUMmPdmTlQAzN09U7nPSyH/KTT/GHEkKT0VW07hk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C5D21E8037 for ; Mon, 15 Apr 2013 18:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.184 X-Spam-Level: X-Spam-Status: No, score=-110.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STN77mC8FyfK for ; Mon, 15 Apr 2013 18:16:00 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id C94CE21F93E1 for ; Mon, 15 Apr 2013 18:15:59 -0700 (PDT) X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="4.87,480,1363150800"; d="scan'208,217";a="107867780" From: To: Date: Mon, 15 Apr 2013 20:15:57 -0500 Thread-Topic: IEEE 802 March Plenary - New Study Groups Thread-Index: Ac46P8ySWTEcM7I9QXyl0ZzcHE2xJA== Message-ID: <93720FE55DA3044C9F74B2962338F7DEC3CC7B61A9@AUSX7MCPC109.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============6580766345967963184==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 15 Apr 2013 18:17:55 -0700 Subject: [secdir] [new-work] IEEE 802 March Plenary - New Study Groups X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 01:16:03 -0000 --===============6580766345967963184== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_93720FE55DA3044C9F74B2962338F7DEC3CC7B61A9AUSX7MCPC109A_" --_000_93720FE55DA3044C9F74B2962338F7DEC3CC7B61A9AUSX7MCPC109A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Members of IETF, In the spirit of continuing cooperation between IEEE 802 and IETF, the foll= owing letter addresses new work items for information and potential coordin= ation with the respective IEEE 802 WG. One of the first steps in the IEEE Standards Association's standards develo= pment process is the creation of a Study Group. Study groups are chartered = to create a formal Project Authorization Request (PAR) document that includ= es a description of the project's scope and purpose. The following Study Groups were approved at the March 2013 IEEE 802 Plenary= - 1. IEEE 802.3, "400 Gb/s Ethernet" Study Group 2. IEEE 802.3, "4-pair Power over Ethernet" Study Group 3. IEEE 802.11, "High Efficiency WLAN" Study Group Further information about these Study Groups may be found at http://www.iee= e802.org/StudyGroups.shtml. Please note, per the IEEE 802 Policies and Procedures that a Study Group is= chartered to operate from plenary session-to-plenary session, a period of = four months and, if it wishes to continue, must request a charter extension= . Therefore, the Study Groups, listed above are chartered until the IEEE 80= 2 July 2013 Plenary Session. Study Groups may also terminate between plenar= y sessions if their proposed project is approved by the IEEE Standards Asso= ciation Standards Board. Additionally, within the IEEE 802 family of standards, there is a requireme= nt that each new project proposal attaches additional documentation that de= scribes its engineering feasibility, market potential, assurance of coexist= ence and distinct identity relative to previous standards (referred to as t= he "five criteria" in 802). The "five criteria" used by IEEE 802 can be fou= nd in document: https://mentor.ieee.org/802-ec/dcn/13/ec-13-0002-01-00EC-five-criteria-om-e= xtract-informative.doc Also please note that IEEE meetings are open and may be attended by any ind= ividuals who register and fulfill any registration fees. Details regarding = future IEEE 802 plenary meeting schedules may be found at http://www.ieee80= 2.org/PARs.shtml. Please refer to individual working groups for their inter= im meeting schedules. A listing of all working groups may be found at http:= //www.ieee802.org/. Sincerely, John D'Ambrosia Recording Secretary, IEEE 802 LMSC jdambrosia@ieee.org --_000_93720FE55DA3044C9F74B2962338F7DEC3CC7B61A9AUSX7MCPC109A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Members of IETF,

 

In the spirit of continuing cooperation = between IEEE 802 and IETF, the following letter addresses new work items fo= r information and potential coordination with the respective IEEE 802 WG.

 

One of = the first steps in the IEEE Standards Association’s standards develop= ment process is the creation of a Study Group. Study groups are chartered t= o create a formal Project Authorization Request (PAR) document that include= s a description of the project’s scope and purpose.

 

The following Study = Groups were approved at the March 2013 IEEE 802 Plenary – =

  1. IEEE 802.3, &quo= t;400 Gb/s Ethernet" Study Group
  2. IEEE 802.3, "4-pair Power over Ethernet" Study Group
  3. IEEE 802.11, "Hig= h Efficiency WLAN" Study Group

Further informati= on about these Study Groups may be found at http://www.ieee802.org/StudyGroups.shtml.  =

 

Plea= se note, per the IEEE 802 Policies and Procedures that a Study Group is cha= rtered to operate from plenary session-to-plenary session, a period of four= months and, if it wishes to continue, must request a charter extension. Th= erefore, the Study Groups, listed above are chartered until the IEEE 802 Ju= ly 2013 Plenary Session. Study Groups may also terminate between plenary se= ssions if their proposed project is approved by the IEEE Standards Associat= ion Standards Board.

=

Additionally, within the IEEE 802 family of standards, there is a= requirement that each new project proposal attaches additional documentati= on that describes its engineering feasibility, market potential, assurance = of coexistence and distinct identity relative to previous standards (referr= ed to as the “five criteria” in 802). The “five criteria&= #8221; used by IEEE 802 can be found in document:

 

https://mentor.ieee.org/802-ec/dcn/13/ec-13-0002-01-00EC-five-criteria= -om-extract-informative.doc 

&n= bsp;

Also please note that IEEE meetings are open= and may be attended by any individuals who register and fulfill any regist= ration fees. Details regarding future IEEE 802 plenary meeting schedules ma= y be found at http://www.ieee80= 2.org/PARs.shtml. Please refer to individual working groups for their int= erim meeting schedules. A listing of all working groups may be found at http://www.ieee802.org/.  =

&nb= sp;

Sincerely,

=  

= John D’Ambrosia

Recording Secretary, IEEE 802 LMSC=

jdambrosia@ieee.org=

= --_000_93720FE55DA3044C9F74B2962338F7DEC3CC7B61A9AUSX7MCPC109A_-- --===============6580766345967963184== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============6580766345967963184==-- From new-work-bounces@ietf.org Tue Apr 16 09:14:28 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFEE21F9786; Tue, 16 Apr 2013 09:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1366128868; bh=X9p5lOZG2X1AhcUQ78MPU9X/idbfbkgyRyNVbaq+gNo=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=sV6e2jZTt7y1nD/kLAswLoELX6GBU8w/wNavUeNpp5HV+HXpsGZhc5mk1X9TB0GeJ 0DMo2uAlM4+jBh4/RHUTUm5/flKb80UBloxtp39UBGjsQibL9hjlBDvDOJyzcLgEP+ a7f0fxMC/5rUOX2oxn3zMxs9XQdipNKQfWxOCR5U= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C478D21F9786; Tue, 16 Apr 2013 09:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8QZI6hrjGCC; Tue, 16 Apr 2013 09:14:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 979C621F9784; Tue, 16 Apr 2013 09:14:26 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130416161425.20599.63753.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 09:14:25 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 16 Apr 2013 09:15:43 -0700 Subject: [secdir] [new-work] WG Review: Javascript Object Signing and Encryption (jose) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 16:14:28 -0000 The Javascript Object Signing and Encryption (jose) working group in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-04-23. Javascript Object Signing and Encryption (jose) ------------------------------------------------ Current Status: Active Working Group Chairs: Karen O'Donoghue Jim Schaad Assigned Area Director: Sean Turner Mailing list Address: jose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jose Archive: http://www.ietf.org/mail-archive/web/jose/ Charter of Working Group: JavaScript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services for JSON with encryption, digital signatures, and message authentication codes (MACs). Different proposals for providing such security services have already been defined and implemented. This Working Group will standardize the mechanism for integrity protection (signature and MAC) and encryption as well as the format for keys and algorithm identifiers to support interoperability of security services for protocols that use JSON. The Working Group will base its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is sound. The WG will strive to gather use cases to ensure the broadest possible applicability of the mechanism. As JSON adoption expands, the different applications utilizing JSON security services will grow and this leads to the need to support different requirements. The WG will develop a generic syntax that can be used by applications to secure JSON-data, but it will be up to the application to fully specify the use of the WG's documents much the same way S/MIME is the application of CMS to MIME-based media types. This group is chartered to work on the following deliverables: (1) A Standards Track document or documents representing integrity-protected data using JSON-based data structures, including (but not limited to) JSON data structures. "Integrity protection" includes public-key digital signatures as well as symmetric-key MACs. (2) A Standards Track document or documents representing encrypted data using JSON-based data structures, including (but not limited to) JSON data structures. (3) A Standards Track document specifying how to encode public keys as JSON- structured objects. (4) A Standards Track document specifying algorithms and algorithm identifiers for the previous three documents. (5) A Standards Track document specifying how to encode private and symmetric keys as JSON-structured objects. This document will build upon the concepts and structures in (3). (6) A Standards Track document specifying a means of protecting private and symmetric keys via encryption. This document will build upon the concepts and structures in (2) and (5). This document may register additional algorithms in registries defined by (4). (7) An Informational document detailing Use Cases and Requirements for JSON Object Signing and Encryption (JOSE). (8) An Informational document that tells an application what needs to be specified in order to implement JOSE. One or more of these goals may be combined into a single document, in which case the concrete milestones for these goals will be satisfied by the consolidated document(s). Milestones: Jan 2012 - Submit JSON object integrity document as a WG item. Jan 2012 - Submit JSON object encryption document as a WG item. Jan 2012 - Submit JSON key format document as a WG item. Jan 2012 - Submit JSON algorithm document as a WG item. Jun 2012 - Start Working Group Last Call on JSON object integrity document. Jun 2012 - Start Working Group Last Call on JSON object encryption document. Jun 2012 - Start Working Group Last Call on JSON key format document. Jun 2012 - Start Working Group Last Call on JSON algorithm document. Jul 2012 - Submit JSON object integrity document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON object encryption document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON key format document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON algorithm document to IESG for consideration as Standards Track document. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Apr 16 09:23:52 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF18421F979B; Tue, 16 Apr 2013 09:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1366129432; bh=qVdjPPGoFC+045jiN75uyBvlOcbqa8f2eneY7ZsmrkA=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=SJqkyAFll4dVW+HVb3SkvEvhTmSd9UctLSwrt39Cp6febYNXxvu9rlG/iqLaDOTFm cyr1ov6Nk+q98jE5ksbcJ1QSolYaOrnkaP9/GnzQPkH14xiiX0svDXmPo39JC5HS97 to8MswfQKkGrIYI60V3fJmx0drFL/emRV5CWkTeM= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B920C21F96C1; Tue, 16 Apr 2013 09:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KICG1pfJFCwj; Tue, 16 Apr 2013 09:23:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F16E21F978E; Tue, 16 Apr 2013 09:23:47 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130416162346.19227.92027.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 09:23:46 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 16 Apr 2013 09:33:49 -0700 Subject: [secdir] [new-work] WG Review: IMAP QRESYNC Extension (qresync) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 16:23:52 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-04-23. IMAP QRESYNC Extension (qresync) ------------------------------------------------ Current Status: Proposed Working Group Assigned Area Director: Barry Leiba Mailing list Address: imapext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/imapext Archive: http://www.ietf.org/mail-archive/web/imapext/ Charter of Working Group: The Internet Message Access Protocol (IMAP), defined in RFC 3501, specifies a protocol for accessing email messages on a server that implements a message store from a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming mailboxes, adding a message to a mailbox, and copying messages from one mailbox to another. Base IMAP as described in RFC 3501 requires that in order to discover flag changes and expunged messages in a mailbox, the client has to fetch flags for all messages it knows in the mailbox and compare returned results with its own state. This can generate a significant amount of traffic for big mailboxes. The IMAP CONDSTORE extension (RFC 4551) provides a facility for IMAP clients to quickly resynchronize mailbox flag changes in a mailbox. The IMAP QRESYNC extension (RFC 5162) extends CONDSTORE to also cover expunged messages, and reduces the number of round trips needed to resynchronize by extending the SELECT/EXAMINE command. The CONDSTORE and QRESYNC extensions are deployed in both clients and servers. These deployments have exposed errors and clarity issues in the specifications, and they need correcting. The IMAP QRESYNC Extension working group has the task of updating CONDSTORE and QRESYNC extensions on the Standards Track. The working group might produce one (combined) or two separate documents (as now) updating these extensions. The working group will review errata and update the documents as needed to incorporate those, and will correct significant errors and inconsistencies, but will keep changes at this stage to a minimum and avoid incompatible changes. No other IMAP extension work is in scope for this working group. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From jsalowey@cisco.com Tue Apr 16 13:43:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E6821F9748; Tue, 16 Apr 2013 13:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTTU1MFf1DjJ; Tue, 16 Apr 2013 13:43:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DB09121F973B; Tue, 16 Apr 2013 13:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1424; q=dns/txt; s=iport; t=1366144982; x=1367354582; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=BU4oh9O5GM/VNVZLbE74hizh92+JqGVG/OK/9hNYPCE=; b=FyLeHm8xVkJ6HreZguXgCzo2en/Nnye+utKm/jQFBue7H1P2xgCPoWON 04hyqi9ax+t9Brp1hsOqdD3aLH385NMz0LDX5+BzrYuZh1ZkeZ5Km+E6E 77VoRE6x+npe6lQq5db3Uhf4p9PpDL3s5WMYvWkuGIF2r+qo6/9dEZojV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPa2bVGtJV2Y/2dsb2JhbABQgwbBNIELFnSCIQEEOlEBKhRCJwQBGogMrE+QNo5qgxxhA6gagwuCKA X-IronPort-AV: E=Sophos;i="4.87,487,1363132800"; d="scan'208";a="199510018" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 16 Apr 2013 20:43:01 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3GKh1Bl032476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 20:43:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 15:43:01 -0500 From: "Joseph Salowey (jsalowey)" To: "secdir@ietf.org" , The IESG , "draft-ietf-opsec-ipv6-implications-on-ipv4-nets.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 Thread-Index: AQHOOuL82kKZssNyFEuJtkLLRgrBFg== Date: Tue, 16 Apr 2013 20:43:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.250.110] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 20:43:03 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. I consider this document ready with issues described below. =20 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 discusses issues with IP= v6 running on networks that have incomplete security controls (firewall and= IDS) for IPv6. It basically describes what you need to filter on to fil= ter out IPv6 traffic and tunneling technologies. This seems like mostly u= seful information, however its not clear to me if you implement all the con= trols in the document if you would not still have a problem form IPv6 on a = local link or IPv6 tunneled through some non-standard means. It seems the = document should at least mention this risk in the security considerations s= ince hosts on these networks may be IPv6 enabled. One related issue I ha= ve seen is in end host configuration where a host based firewall is configu= red with IPv4 rules and left silent on IPv6 with varying results. I don't= recall seeing any discussion of this in the document, but it might also be= worth covering in security considerations as well.=20 Cheers, Joe From fgont@si6networks.com Tue Apr 16 16:06:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E0F21F97B9; Tue, 16 Apr 2013 16:06:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4F4cmjRk7Ku; Tue, 16 Apr 2013 16:06:48 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CA9D521F97C2; Tue, 16 Apr 2013 16:06:47 -0700 (PDT) Received: from [148.220.230.158] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1USExW-0008Na-QU; Wed, 17 Apr 2013 01:06:42 +0200 Message-ID: <516DD980.10806@si6networks.com> Date: Tue, 16 Apr 2013 18:06:40 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-opsec-ipv6-implications-on-ipv4-nets.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 23:06:48 -0000 Hi, Joseph, Thanks so much for your review! -- Please find my comments in-line.... On 04/16/2013 03:43 PM, Joseph Salowey (jsalowey) wrote: > draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 discusses issues > with IPv6 running on networks that have incomplete security controls > (firewall and IDS) for IPv6. It basically describes what you need > to filter on to filter out IPv6 traffic and tunneling technologies. > This seems like mostly useful information, however its not clear to > me if you implement all the controls in the document if you would not > still have a problem form IPv6 on a local link This is discussed in the "native IPv6 section" > or IPv6 tunneled > through some non-standard means. How about adding this a the end of Section 3: "We note that this document covers standardized IPv6 tunneling mechanisms, but does not aim to cover non-standard tunneling mechanisms nor that of IPsec-based or SSL/TLS-based tunneling of IPv6 packets". ? > It seems the document should at > least mention this risk in the security considerations since hosts on > these networks may be IPv6 enabled. One related issue I have seen > is in end host configuration where a host based firewall is > configured with IPv4 rules and left silent on IPv6 with varying > results. I don't recall seeing any discussion of this in the > document, but it might also be worth covering in security > considerations as well. Isn't this covered in the "native ipv6" section? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Tom.Haynes@netapp.com Tue Apr 16 17:13:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6A721F968C; Tue, 16 Apr 2013 17:13:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJW9ustpaE-W; Tue, 16 Apr 2013 17:13:01 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7BA21F9614; Tue, 16 Apr 2013 17:13:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,488,1363158000"; d="scan'208";a="41326884" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 16 Apr 2013 17:13:01 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r3H0D05Q024082; Tue, 16 Apr 2013 17:13:01 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.213]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 17:13:00 -0700 From: "Haynes, Tom" To: Yoav Nir Thread-Topic: SecDir review of draft-ietf-nfsv4-rfc3530bis-25 Thread-Index: AQHONETOGWagEh4py0udbBA2y+BXSZjaDXIA Date: Wed, 17 Apr 2013 00:13:00 +0000 Message-ID: <93075B62-9796-47F9-89D6-690BB7CE0FF6@netapp.com> References: <4DCE9E87-2EF9-4E40-8A33-AB3AF4A11F88@checkpoint.com> In-Reply-To: <4DCE9E87-2EF9-4E40-8A33-AB3AF4A11F88@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-nfsv4-rfc3530bis.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-nfsv4-rfc3530bis-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 00:13:02 -0000 Yoav, Thank you for the effort of reviewing this document. (top-posting because of inline comments) Tom On Apr 8, 2013, at 3:35 AM, Yoav Nir wrote: > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. >=20 > Summary: In my opinion, this I-D needs more work. >=20 > This is a huge draft. It's on track to become the 3rd biggest RFC behind = the security glossary and the NFS 4.1 RFC (5661). I've spent more time on t= his than my previous SECDIR reviews combined, and I still don't think I've = done a thorough enough job. This revision splits RFC 3530 in two: this docu= ment, and the XDR document. This is the third revision of the NFSv4 spec (a= fter 3530 and 3010). RFC 3010 was published on December 2000, over 12 years= ago. It may have been a good idea back then to write the spec as a compari= son to previous specifications, but I don't think this makes sense 12 years= later. As an example, we need look no further than the Abstract: >=20 > The Network File System (NFS) version 4 is a distributed filesystem > protocol which owes heritage to NFS protocol version 2, RFC 1094, and > version 3, RFC 1813. Unlike earlier versions, the NFS version 4 > protocol supports traditional file access while integrating support > for file locking and the mount protocol. >=20 > And it goes on throughout the document - always a diff from NFS 3. That k= ind of voice makes sense when addressing a community with significant NFS 3= experience, and little or no NFS 4 experience. Is this still the case?=20 >=20 > The Introduction section does not talk at all about what NFS is and what = it could possibly be used for. It's just a series of sections detailing dif= ferences from version 3, from 3530, and from 3010. Nowhere does it say why = we need a revision of version 4, when version 4.1 is already published. An editorial decision was to try to not reference RFC 5661 as much as possi= ble and to not cause the reader to go to RFC 3530 for clarification. I.e., = the IANA section is verbatim in order to allow the reader to get it all in = one place. I've modified the Intro to push the first two sections to the end. That sta= rts off with the push to the NFSv2 and NFSv3 documents. > Much of the text is taken from RFC 3530, and in some places it gets weird= : > - Section 11 talks about requirements for future minor versions. Except t= hat unlike when 3530 was published, now a minor version already exists. But= the text ignores it, and talks in the future tense. > - Section 18 instructs IANA to set up a "NFSv4 Named Attribute Definitio= ns Registry". That registry has been up since 2009 >=20 I did add a sentence about how the registry already exists. > OK. On to security things. Section 3.2.1 talks about security mechanisms= . There's this table on page 27 that lists some algorithms, and have DES an= d MD5. This looks really bad for something published in 2013. I understand = that this relates to the deployed base of Kerberos, and the IETF mailing li= st has an active thread about this:=20 > http://www.ietf.org/mail-archive/web/ietf/current/msg78389.html >=20 > Other security issues, such as discussions of ACLs, locks, and the handli= ng of edge conditions (9.6.3.4) seem OK. >=20 > The Security Considerations section again begins with a discussion of pre= vious versions. Beyond that, it can be summarized as these bullet points: > - Authentication is end-to-end > - Translation from NFS identity to local identity needs to be secure (but= it doesn't say secure against what. What is the "integrity of the translat= ion"?) > - These security mechanisms are optional, but SECINFO and GETATTR should = (no RFC 2119 language) be secured. > - For SETCLIENTID/SETCLIENTID_CONFIRM, it's imperative (again, no RFC 211= 9 language) to check the principal against that of previous requests. >=20 > Not being familiar with operational NFS environments, I don't see anythin= g missing from this. >=20 >=20 > NITS: > - There's this weird thing in section 1.5.1, where it says "As with previ= ous versions of NFS, XDR and RPC mechanisms used for NFSv4 are those define= d in RFC5531 and RFC4506". NFSv4 was first defined in RFC 3010, so it proba= bly uses some mechanism from earlier versions of those documents. So "previous versions" means NFSv2 and NFSv3.=20 > - In section 6.4.1.1, "Access mask bits other those listed above". There'= s a missing "than" between the "other" and the "those". Fixed > - Section 9.1.1 discusses the Client ID. The id is generated by the clien= t and has to be unique. Several methods of generating this ID are discussed= . Finally, on page 107 a true random number is suggested (might be better t= o say "pseudo-random number") , and then the text says: > However since this number ought to be > the same between client incarnations, this shares the same > problem as that of the using the timestamp of the software > installation. > Where "between client incarnations" means "across client reboots". But th= is requirement ("ought to") is never explained. I get that if the id change= s, all the locks will be broken, but does any system expect locks to remain= across client reboots? If so, I think it should be explicitly said. Besides client reboots, there is an issue of network partitioning. In that = case, the client may believe that the server rebooted and the server may believe that the client rebooted. But actually, neither did. In = such a scenario, if the client can identify itself properly, then lock state can quickly be recovered. >=20 > Yoav >=20 From Tom.Haynes@netapp.com Tue Apr 16 17:16:10 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF2B21F96BA; Tue, 16 Apr 2013 17:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZYQEE706gcl; Tue, 16 Apr 2013 17:16:09 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A73A321F96B1; Tue, 16 Apr 2013 17:16:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,488,1363158000"; d="scan'208,217";a="41327775" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 16 Apr 2013 17:16:09 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r3H0G9V7027416; Tue, 16 Apr 2013 17:16:09 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.213]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 17:16:09 -0700 From: "Haynes, Tom" To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= Thread-Topic: Secdir review of draft-ietf-nfsv4-rfc3530bis-dot-x-16 Thread-Index: AQHOOaGwbw2pkgFJhUGOof48vd6FlJjaA5kA Date: Wed, 17 Apr 2013 00:16:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/alternative; boundary="_000_D3C85B3C1FD34ED881953AEB2B984C89netappcom_" MIME-Version: 1.0 Cc: "" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-nfsv4-rfc3530bis-dot-x-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 00:16:10 -0000 --_000_D3C85B3C1FD34ED881953AEB2B984C89netappcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 14, 2013, at 11:22 PM, Magnus Nystr=F6m > wrote: I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like any= other last call comments. This NFSv4.0 document provides the XDR definition for NFSv4.0. As such, exc= ept for the introductory section and standard sections towards the end, it = consists entirely of extractable, machine-readable declarations and definit= ions. The Security Considerations section simply refers to the rfc2530bis main do= cument. This may be sufficient; however, if the NFSv4.0 XDR definition intr= oduces any new parsing risks (for example, anything related to internationa= lization?), then it may be better placed in this document. -- Magnus Hi Magnus, That simply becomes too unwieldily. We have another example of this, RFC 5661 and 5662. I always look at RFC 56= 61 and I rarely look at RFC 5662. My expectation is that this is the way others work. I would prefer to leave the internationalization work back in the main docu= ment. Thanks, Tom --_000_D3C85B3C1FD34ED881953AEB2B984C89netappcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Apr 14, 2013, at 11:22 PM, Magnus Nystr=F6m <magnusn@gmail.com> wrote:

I have reviewed this do= cument as part of the security directorate's ongoing effort to review all I= ETF documents being processed by the IESG.  These comments were writte= n primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments= just like any other last call comments.

This NFSv4.0 document provides the XDR definition for NFSv4.0. As such, = except for the introductory section and standard sections towards the end, = it consists entirely of extractable, machine-readable declarations and defi= nitions.

The Security Considerations section simply refers to the rfc2530bis main= document. This may be sufficient; however, if the NFSv4.0 XDR definition i= ntroduces any new parsing risks (for example, anything related to internati= onalization?), then it may be better placed in this document.

-- Magnus


Hi Magnus,

That simply becomes too unwieldily. 

We have another example of this, RFC 5661 and 5662. I always look at R= FC 5661 and I rarely look at RFC 5662.

My expectation is that this is the way others work.

I would prefer to leave the internationalization work back in the main= document.

Thanks,
Tom
--_000_D3C85B3C1FD34ED881953AEB2B984C89netappcom_-- From magnusn@gmail.com Tue Apr 16 17:29:16 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD75F21F9425; Tue, 16 Apr 2013 17:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbPidcNcc4wk; Tue, 16 Apr 2013 17:29:16 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6E921F93EA; Tue, 16 Apr 2013 17:29:15 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id x43so854348wey.28 for ; Tue, 16 Apr 2013 17:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+6zbAy4HFoYuC1QvZ+UEzAuOnjyY1/Z5CoX+5jIbeSI=; b=OJU+HVRuyBdFz9aIUYMJHFYIHezOiA7j8Mx7hDo0FwPRGOH1MDo4IBV3fKWrX+q/5K shrPqCO9RqJEW4VqcqOcP53Vu4dEGVVgmFq00875FM/cSqonYzYJby8DJ1AnWFECBU3p s+m9FAnZVyIUMubjYjMIn6w2I7zeq6CnIuktx93hShu5pfZDC4TGZb1kUlGEWsLC5Ymo JtcCCpwTBUJzqaQKi4dagscuu+l7hrtiz471C3P77uq0aTPmMEOm+5qk524dRgfm9hMw F3LoVQ/YNuieWgzoKG/Hknq/d35rKdjYUrPm/KYsFUX+uYwov188XRFWBtgqa5uifQy3 ociQ== MIME-Version: 1.0 X-Received: by 10.194.8.99 with SMTP id q3mr7060673wja.34.1366158554645; Tue, 16 Apr 2013 17:29:14 -0700 (PDT) Received: by 10.180.85.202 with HTTP; Tue, 16 Apr 2013 17:29:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Apr 2013 17:29:14 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "Haynes, Tom" Content-Type: multipart/alternative; boundary=047d7b5d65925b4f1c04da83930d Cc: "" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-nfsv4-rfc3530bis-dot-x-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 00:29:16 -0000 --047d7b5d65925b4f1c04da83930d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tom, lest there be any misunderstanding: What I suggested was, that it may make sense to discuss how internationalization aspects as they pertain to the XDR itself may impact security in this document's security consideration section. If the main 2530bis document already discusses internationalization aspects covering also XDR aspects then I don't see a strong need to add it to this one. Thanks, /M On Tue, Apr 16, 2013 at 5:16 PM, Haynes, Tom wrote: > > On Apr 14, 2013, at 11:22 PM, Magnus Nystr=F6m wrote= : > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security ar= ea > directors. Document editors and WG chairs should treat these comments jus= t > like any other last call comments. > > This NFSv4.0 document provides the XDR definition for NFSv4.0. As such, > except for the introductory section and standard sections towards the end= , > it consists entirely of extractable, machine-readable declarations and > definitions. > > The Security Considerations section simply refers to the rfc2530bis main > document. This may be sufficient; however, if the NFSv4.0 XDR definition > introduces any new parsing risks (for example, anything related to > internationalization?), then it may be better placed in this document. > -- Magnus > > > > Hi Magnus, > > That simply becomes too unwieldily. > > We have another example of this, RFC 5661 and 5662. I always look at RFC > 5661 and I rarely look at RFC 5662. > > My expectation is that this is the way others work. > > I would prefer to leave the internationalization work back in the main > document. > > Thanks, > Tom > --=20 -- Magnus --047d7b5d65925b4f1c04da83930d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tom, lest there be any misunderstanding: What I su= ggested was, that it may make sense to discuss how internationalization asp= ects as they pertain to the XDR itself may impact security in this document= 's security consideration section. If the main 2530bis document already= discusses internationalization aspects covering also XDR aspects then I do= n't see a strong need to add it to this one.
Thanks,
/M


On Tue, Apr 16, 2013 at 5:16 PM, Haynes, Tom <= Tom.Haynes@netapp.com> wrote:

On Apr 14, 2013, at 11:22 PM, Magnus Nystr=F6m <magnusn@gmail.com> wrote:

I have reviewed this do= cument as part of the security directorate's ongoing effort to review a= ll IETF documents being processed by the IESG. =A0These comments were writt= en primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments= just like any other last call comments.

This NFSv4.0 document provides the XDR definition for NFSv4.0. As such, = except for the introductory section and standard sections towards the end, = it consists entirely of extractable, machine-readable declarations and defi= nitions.

The Security Considerations section simply refers to the rfc2530bis main= document. This may be sufficient; however, if the NFSv4.0 XDR definition i= ntroduces any new parsing risks (for example, anything related to internati= onalization?), then it may be better placed in this document.

-- Magnus


Hi Magnus,

That simply becomes too unwieldily.=A0

We have another example of this, RFC 5661 and 5662. I always look at R= FC 5661 and I rarely look at RFC 5662.

My expectation is that this is the way others work.

I would prefer to leave the internationalization work back in the main= document.

Thanks,
Tom



--
-- Magnus
--047d7b5d65925b4f1c04da83930d-- From jsalowey@cisco.com Wed Apr 17 07:38:51 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C17121F8AA6; Wed, 17 Apr 2013 07:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugCPPshCaIWT; Wed, 17 Apr 2013 07:38:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C234721F8709; Wed, 17 Apr 2013 07:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2597; q=dns/txt; s=iport; t=1366209530; x=1367419130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=roljc+PYDFYGHcdYwQe+/RqruuaQueggIQYZbqMzAKw=; b=b+A29Ot17dX7ODUnTv5EgURnLElztQVkI4NH0CoCi5aFYO6/1L1wHoak 2D4pfy2odOllO6dvhhfFKg3U3HE+8xC4TkEx4iIqXW6rJkI+6htHFFmAb YRPPFEFZXR9jXFLs890FuK6+Vq9Ib1tw+Izh0B5BwQQWEyF6qrc13apfC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAM6xblGtJXHB/2dsb2JhbABQgwbBQoEDFnSCHwEBAQMBeQULAgEIDgoKJDIlAgQOBQiIBga9Uo1ofwIxB4JlYQOITp9MgwuBczU X-IronPort-AV: E=Sophos;i="4.87,492,1363132800"; d="scan'208";a="199894410" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 17 Apr 2013 14:38:50 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3HEcoej004704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 14:38:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 09:38:49 -0500 From: "Joseph Salowey (jsalowey)" To: Fernando Gont Thread-Topic: Secdir review of draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 Thread-Index: AQHOOuL82kKZssNyFEuJtkLLRgrBFpjZzCYAgAEEcAA= Date: Wed, 17 Apr 2013 14:38:48 +0000 Message-ID: References: <516DD980.10806@si6networks.com> In-Reply-To: <516DD980.10806@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.120.65] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2AFE086DE3EDB4428054CC8D9F2552A7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-opsec-ipv6-implications-on-ipv4-nets.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 14:38:51 -0000 On Apr 16, 2013, at 4:06 PM, Fernando Gont wrote: > Hi, Joseph, >=20 > Thanks so much for your review! -- Please find my comments in-line.... >=20 > On 04/16/2013 03:43 PM, Joseph Salowey (jsalowey) wrote: >> draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 discusses issues >> with IPv6 running on networks that have incomplete security controls >> (firewall and IDS) for IPv6. It basically describes what you need >> to filter on to filter out IPv6 traffic and tunneling technologies. >> This seems like mostly useful information, however its not clear to >> me if you implement all the controls in the document if you would not >> still have a problem form IPv6 on a local link=20 >=20 > This is discussed in the "native IPv6 section" >=20 [Joe] Yes. I might have chosen to include a stronger statement about"you a= re not going to be able to filter out all IPv6 attacks" in the security con= siderations section, but the first paragraph pretty much says this. =20 >=20 >> or IPv6 tunneled >> through some non-standard means. >=20 > How about adding this a the end of Section 3: >=20 > "We note that this document covers standardized IPv6 tunneling > mechanisms, but does not aim to cover non-standard tunneling mechanisms > nor that of IPsec-based or SSL/TLS-based tunneling of IPv6 packets". >=20 [Joe] OK > ? >=20 >=20 >> It seems the document should at >> least mention this risk in the security considerations since hosts on >> these networks may be IPv6 enabled. One related issue I have seen >> is in end host configuration where a host based firewall is >> configured with IPv4 rules and left silent on IPv6 with varying >> results. I don't recall seeing any discussion of this in the >> document, but it might also be worth covering in security >> considerations as well. >=20 > Isn't this covered in the "native ipv6" section? [Joe] I was thinking of having some text that is a bit more host centric. = Currently the text reads more oriented towards network devices. THere is= some discussion on disabling IPv6 in extreme circumstances. Would it be u= seful to recommend that IP filters on IPV6 end hosts be configured to apply= controls to IPv6 as well as IPv4 since there is a fair chance that the hos= ts services may be listening on an IPv6 address as well? =20 >=20 > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From mlepinski.ietf@gmail.com Wed Apr 17 13:22:27 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727EB21E809D; Wed, 17 Apr 2013 13:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-PJqi7GAeuT; Wed, 17 Apr 2013 13:22:19 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id 98F0121E809B; Wed, 17 Apr 2013 13:22:15 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id b10so1168241qen.28 for ; Wed, 17 Apr 2013 13:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=f7+M9b+Udb1oRFPFNeH1OISIa9yr6cOzXVRe1oRu2CE=; b=QEmhAe46e4r8vkAXLf5RM9GgL6cd5i2pev9Q1m/h3fi0gvDZZA7UJ3qnvHlPswHTao DAEv00i2uism6BG/ObrgRfPccYgiL390DaSr3KSok2ctm0amrM9ngB7xr+aSodgbDB2m /7wswXnoxrIpAZHz6svU1a8pXqVRbAqw2KgoxraGyy8nzUzUvHgwmTrlUCqw54RxxkNk /4BoFd0LX/3EYJBzebsJx56Z5GXgLPG37XuO11s4B2MXv0ShQ/bbZpB7yZPgZgsjM/CA hcWjR7Oc1WnQdlDSf2rWmDHLUbpH8m6KRU6Ryu/UbNWT0JHZkjJSz0wtgqbwhnwhXqjl DhHQ== MIME-Version: 1.0 X-Received: by 10.224.105.83 with SMTP id s19mr2406786qao.28.1366230135078; Wed, 17 Apr 2013 13:22:15 -0700 (PDT) Received: by 10.49.81.209 with HTTP; Wed, 17 Apr 2013 13:22:14 -0700 (PDT) Date: Wed, 17 Apr 2013 16:22:14 -0400 Message-ID: From: Matthew Lepinski To: secdir@ietf.org, iesg@ietf.org Content-Type: multipart/alternative; boundary=20cf305e1fdbe2059004da943d1e Cc: draft-ietf-xrblock-rtcp-xr-burst-gap-discard.all@tools.ietf.org Subject: [secdir] SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 20:22:27 -0000 --20cf305e1fdbe2059004da943d1e Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: In my opinion this document is acceptable. I have no concerns with this document. This document describes a new RTCP block for use in the RTCP eXtended Reporting (XR) framework. The block specified in this protocol is a companion to the block specified in draft-ietf-xrblock-rtcp-xr-discard. Where I-D.xrblock-rtcp-xr-discard allows a receiver to report the number of packets discarded without being used (played out), this current draft allows a receiver to provide additional data regarding the pattern of discarded packets. That is, how many of the discarded packets arrived during intervals of high discard rate (i.e., intervals of poor quality due to many discards). The document authors claim that this draft introduces no new security considerations beyond those described in RFC 3611 (RTCP eXtended Reports). I agree with this assessment. I did have one minor question about Section 3.2. I admit that I am not an RTCP expert, but I was confused by the description of the Threshold value. The document says that the Threshold is calculated in the same way Gmin is calculated in 3611. However, in 3611 it appears that Gmin is a value configured by the receiver (Recommended to be 16, but can be set to any non-zero value the receiver desires.) Am I correct in assuming that Threshold is also a configured value sent by the receiver? Finally, do you expect implementations to use both the VoIP Metrics block and the Burst/Gap Discard block together (for the same RTP session)? If so, is it important that the Threshold in the Burst/Gap Discard block be set to the same value as the Gmin value in the VoIP Metrics block? (If there are any problems that would arise if the two parameters were set to different values, those should be mentioned. If there are no anticipated issues with setting the values independently, then that's fine there is no need to say anything more than is currently in the document.) --20cf305e1fdbe2059004da943d1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dir= ectorate's ongoing effort to review all IETF documents being processed = by the IESG. =A0These comments were written primarily for the benefit of th= e security area directors. =A0Document editors and WG chairs should treat t= hese comments just like any other last call comments.

<= span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">= Summary: In my opinion this document is acceptable. I have no concerns with= this document.

This document describes a new RTCP block for use in the RTCP e= Xtended Reporting (XR) framework. The block specified in this protocol is a= companion to the block specified in=A0draft-ietf-xrblock-rtcp-xr-discard. Where I-D.xrblock-rtcp-xr-disca= rd allows a receiver to report=A0the number of packets discarded without be= ing used (played out), this current draft allows a receiver to provide addi= tional data regarding the pattern of discarded packets. That is, how many o= f the discarded packets arrived during intervals of high discard rate (i.e.= , intervals of poor quality due to many discards).

The document authors claim that this draft introd= uces no new security considerations beyond those described in RFC 3611 (RTC= P eXtended Reports). I agree with this assessment.

I did have one minor question about Section= 3.2. I admit that I am not an RTCP expert, but I was confused by the descr= iption of the Threshold value. The document says that the Threshold is calc= ulated in the same way Gmin is calculated in 3611. However, in 3611 it appe= ars that Gmin is a value configured by the receiver (Recommended to be 16, = but can be set to any non-zero value the receiver desires.) Am I correct in= assuming that Threshold is also a configured value sent by the receiver?= =A0

Finally, do you expect implementation= s to use both the VoIP Metrics block and the Burst/Gap Discard block togeth= er (for the same RTP session)? If so, is it important that the Threshold in= the Burst/Gap Discard block be set to the same value as the Gmin value in = the VoIP Metrics block? (If there are any problems that would arise if the = two parameters were set to different values, those should be mentioned. If = there are no anticipated issues with setting the values independently, then= that's fine there is no need to say anything more than is currently in= the document.)




--20cf305e1fdbe2059004da943d1e-- From Tina.Tsou.Zouting@huawei.com Wed Apr 17 20:27:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DF321E80FA; Wed, 17 Apr 2013 20:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljzMwioLFnOw; Wed, 17 Apr 2013 20:27:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 094B421E80F9; Wed, 17 Apr 2013 20:27:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY27195; Thu, 18 Apr 2013 03:26:57 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Apr 2013 04:26:41 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Apr 2013 04:26:53 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.156]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 17 Apr 2013 20:26:48 -0700 From: Tina TSOU To: "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: SecDir Review of draft-ietf-mpls-tp-ring-protection-05 Thread-Index: AQHOO+SOY0xUhx3HFkmi1wKZRz4i1A== Date: Thu, 18 Apr 2013 03:26:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.146] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8165CD009dfweml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: [secdir] SecDir Review of draft-ietf-mpls-tp-ring-protection-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 03:27:02 -0000 --_000_C0E0A32284495243BDE0AC8A066631A8165CD009dfweml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. It is technically ready, but a few editorial suggestions are below. Typo, second-last paragraph of Section 1, last sentence: s/doxument/document/ Editorial suggestion: introduce the abbreviations P2P and P2MP in their res= pective bullets at the beginning of Section 1.1. According to the RFC Edito= r's list of abbreviations at http://www.rfc-editor.org/rfc-style-guide/abbr= ev.expansion.txt, these are not considered well-known, therefore need to be spelled out on fi= rst use. Note the capitalization, per the RFC Editor's list. In case 3. of Section 1.1, delete "that" after "operator command" in the fi= rst line to make it consistent with the other two cases. Section 1.2 first paragraph last sentence: the subject of the sentence is t= he singular "Requirement", hence s/are/is/ in the final line. The authors can consider whether they need to spell out LSP and LSR at the = start of Section 1.3. Again, the RFC Editor does not consider these to be "= well-known" abbreviations. Second paragraph below Figure 1: The last sentence begins: "Coordination of= the switchover ..." I assume the intention here is to indicate that in thi= s case operation is not so simple as the first sentence indicates. That should perhaps be signalled by beginning the sentence with: "However, coordination of the switchover ..." Sentence before Figure 7: s/complimentary/complementary/ Spell out e2e in the second paragraph below Figure 8, since it is used once= only. Thank you, Tina --_000_C0E0A32284495243BDE0AC8A066631A8165CD009dfweml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

I have reviewed this docu= ment as part of the security directorate's ongoing effort to review all IET= F documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.&nbs= p; Document editors and WG chairs should treat these comments just like any= other last call comments.

 <= /p>

It is technically ready, = but a few editorial suggestions are below.

 <= /p>

Typo, second-last paragra= ph of Section 1, last sentence:

  s/doxument/documen= t/

 <= /p>

Editorial suggestion: int= roduce the abbreviations P2P and P2MP in their respective bullets at the be= ginning of Section 1.1. According to the RFC Editor's list of abbreviations at http://www.rfc-editor.org/rfc-style-guide/abbrev.expan= sion.txt,

these are not considered = well-known, therefore need to be spelled out on first use. Note the capital= ization, per the RFC Editor's list.

 <= /p>

In case 3. of Section 1.1= , delete "that" after "operator command" in the first l= ine to make it consistent with the other two cases.

 <= /p>

Section 1.2 first paragra= ph last sentence: the subject of the sentence is the singular "Require= ment", hence s/are/is/ in the final line.

 <= /p>

The authors can consider = whether they need to spell out LSP and LSR at the start of Section 1.3. Aga= in, the RFC Editor does not consider these to be "well-known" abbreviations.

 <= /p>

Second paragraph below Fi= gure 1: The last sentence begins: "Coordination of the switchover ...&= quot; I assume the intention here is to indicate that in this case operation is not so simple as the first sentence indicates.

That should perhaps be si= gnalled by beginning the sentence with:

"However, coordinati= on of the switchover ..."

 <= /p>

Sentence before Figure 7:= s/complimentary/complementary/

 <= /p>

Spell out e2e in the seco= nd paragraph below Figure 8, since it is used once only.<= /p>

 <= /p>

 <= /p>

Thank you,

Tina

--_000_C0E0A32284495243BDE0AC8A066631A8165CD009dfweml513mbschi_-- From bill.wu@huawei.com Wed Apr 17 23:14:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CF621F8F4F; Wed, 17 Apr 2013 23:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.629 X-Spam-Level: X-Spam-Status: No, score=0.629 tagged_above=-999 required=5 tests=[AWL=-1.821, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VZLDPC2OJXF; Wed, 17 Apr 2013 23:14:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 339ED21F8F1A; Wed, 17 Apr 2013 23:14:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY36730; Thu, 18 Apr 2013 06:13:58 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Apr 2013 07:13:42 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Apr 2013 07:13:54 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.113]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Thu, 18 Apr 2013 14:13:48 +0800 From: Qin Wu To: Matthew Lepinski , "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12 Thread-Index: AQHOO6lNkdOgkRpj0UCIzqzcZ8nnjpjbekQw Date: Thu, 18 Apr 2013 06:13:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43A4C890nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-xrblock-rtcp-xr-burst-gap-discard.all@tools.ietf.org" Subject: [secdir] =?gb2312?b?tPC4tDogU2VjRGlyIFJldmlldyBvZiBkcmFmdC1pZXRm?= =?gb2312?b?LXhyYmxvY2stcnRjcC14ci1idXJzdC1nYXAtZGlzY2FyZC0xMg==?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 06:14:02 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43A4C890nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmsgTWF0dGV3IGZvciB5b3VyIHZhbHVhYmxlIHJldmlldy4NClBsZWFzZSBzZWUgbXkgcmVw bHkgaW5saW5lIGJlbG93Lg0KDQpSZWdhcmRzIQ0KLVFpbg0Kt6K8/sjLOiBNYXR0aGV3IExlcGlu c2tpIFttYWlsdG86bWxlcGluc2tpLmlldGZAZ21haWwuY29tXQ0Kt6LLzcqxvOQ6IDIwMTPE6jTU wjE4yNUgNDoyMg0KytW8/sjLOiBzZWNkaXJAaWV0Zi5vcmc7IGllc2dAaWV0Zi5vcmcNCrOty806 IGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWJ1cnN0LWdhcC1kaXNjYXJkLmFsbEB0b29scy5p ZXRmLm9yZw0K1vfM4jogU2VjRGlyIFJldmlldyBvZiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14 ci1idXJzdC1nYXAtZGlzY2FyZC0xMg0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh cyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJl dmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhl c2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhl IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJz IHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2Fs bCBjb21tZW50cy4NCg0KU3VtbWFyeTogSW4gbXkgb3BpbmlvbiB0aGlzIGRvY3VtZW50IGlzIGFj Y2VwdGFibGUuIEkgaGF2ZSBubyBjb25jZXJucyB3aXRoIHRoaXMgZG9jdW1lbnQuDQoNClRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGEgbmV3IFJUQ1AgYmxvY2sgZm9yIHVzZSBpbiB0aGUgUlRDUCBl WHRlbmRlZCBSZXBvcnRpbmcgKFhSKSBmcmFtZXdvcmsuIFRoZSBibG9jayBzcGVjaWZpZWQgaW4g dGhpcyBwcm90b2NvbCBpcyBhIGNvbXBhbmlvbiB0byB0aGUgYmxvY2sgc3BlY2lmaWVkIGluIGRy YWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWRpc2NhcmQuIFdoZXJlIEktRC54cmJsb2NrLXJ0Y3At eHItZGlzY2FyZCBhbGxvd3MgYSByZWNlaXZlciB0byByZXBvcnQgdGhlIG51bWJlciBvZiBwYWNr ZXRzIGRpc2NhcmRlZCB3aXRob3V0IGJlaW5nIHVzZWQgKHBsYXllZCBvdXQpLCB0aGlzIGN1cnJl bnQgZHJhZnQgYWxsb3dzIGEgcmVjZWl2ZXIgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGRhdGEgcmVn YXJkaW5nIHRoZSBwYXR0ZXJuIG9mIGRpc2NhcmRlZCBwYWNrZXRzLiBUaGF0IGlzLCBob3cgbWFu eSBvZiB0aGUgZGlzY2FyZGVkIHBhY2tldHMgYXJyaXZlZCBkdXJpbmcgaW50ZXJ2YWxzIG9mIGhp Z2ggZGlzY2FyZCByYXRlIChpLmUuLCBpbnRlcnZhbHMgb2YgcG9vciBxdWFsaXR5IGR1ZSB0byBt YW55IGRpc2NhcmRzKS4NCg0KVGhlIGRvY3VtZW50IGF1dGhvcnMgY2xhaW0gdGhhdCB0aGlzIGRy YWZ0IGludHJvZHVjZXMgbm8gbmV3IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGJleW9uZCB0aG9z ZSBkZXNjcmliZWQgaW4gUkZDIDM2MTEgKFJUQ1AgZVh0ZW5kZWQgUmVwb3J0cykuIEkgYWdyZWUg d2l0aCB0aGlzIGFzc2Vzc21lbnQuDQoNCltRaW5dOiBUaGFua3MuDQoNCkkgZGlkIGhhdmUgb25l IG1pbm9yIHF1ZXN0aW9uIGFib3V0IFNlY3Rpb24gMy4yLiBJIGFkbWl0IHRoYXQgSSBhbSBub3Qg YW4gUlRDUCBleHBlcnQsIGJ1dCBJIHdhcyBjb25mdXNlZCBieSB0aGUgZGVzY3JpcHRpb24gb2Yg dGhlIFRocmVzaG9sZCB2YWx1ZS4gVGhlIGRvY3VtZW50IHNheXMgdGhhdCB0aGUgVGhyZXNob2xk IGlzIGNhbGN1bGF0ZWQgaW4gdGhlIHNhbWUgd2F5IEdtaW4gaXMgY2FsY3VsYXRlZCBpbiAzNjEx LiBIb3dldmVyLCBpbiAzNjExIGl0IGFwcGVhcnMgdGhhdCBHbWluIGlzIGEgdmFsdWUgY29uZmln dXJlZCBieSB0aGUgcmVjZWl2ZXIgKFJlY29tbWVuZGVkIHRvIGJlIDE2LCBidXQgY2FuIGJlIHNl dCB0byBhbnkgbm9uLXplcm8gdmFsdWUgdGhlIHJlY2VpdmVyIGRlc2lyZXMuKSBBbSBJIGNvcnJl Y3QgaW4gYXNzdW1pbmcgdGhhdCBUaHJlc2hvbGQgaXMgYWxzbyBhIGNvbmZpZ3VyZWQgdmFsdWUg c2VudCBieSB0aGUgcmVjZWl2ZXI/DQoNCltRaW5dOiBUaGUgdGV4dCB5b3UgYXJlIHJlZmVycmlu ZyB0byAoaS5lLiwgVGhyZXNob2xkIGlzIGNhbGN1bGF0ZWQgaW4gdGhlIHNhbWUgd2F5IEdtaW4g aXMgY2FsY3VsYXRlZCBpbiAzNjExLikgd2FzIGFkZGVkIGNvcnJlc3BvbmRpbmcgdG8gUE0tRElS IHJldmlldy4gWW91IGFyZSByaWdodCwgR21pbiBpcyBjb25maWd1cmF0aW9uIHBhcmFtZXRlciBz ZW50IGJ5IHRoZSByZWNlaXZlci4gR21pbiBjYW4gYmUgb3RoZXIgdmFsdWUgdGhhbiAxNiwgc2Vl IFJGQzM2MTEsIHNlY3Rpb24gNC43LjENCqGwDQpJZiB0aGUgcGFja2V0IHNwYWNpbmcgaXMgMTAg bXMgYW5kIHRoZSBHbWluIHZhbHVlIGlzIHRoZSByZWNvbW1lbmRlZA0KICAgdmFsdWUgb2YgMTYs IHRoZSBidXJzdCBkdXJhdGlvbiBpcyAxMjAgbXMsIHRoZSBidXJzdCBkZW5zaXR5IDAuMzMsDQog ICB0aGUgZ2FwIGR1cmF0aW9uIDIzMCBtcyArIDI5MCBtcyA9IDUyMCBtcywgYW5kIHRoZSBnYXAg ZGVuc2l0eSAwLjA0Lg0KDQqhsQ0KTWF5YmUgdGhlIHdvcmQgobBjYWxjdWxhdGVkobEgaXMgYSBs aXR0bGUgbWlzbGVhZGluZyBhbmQgY2FuIGJlIHJlcGhyYXNlZCBhcyChsHNldKGxLCBpLmUuLA0K VGhlIHRocmVzaG9sZCBpcyBzZXQgaW4gdGhlIHNhbWUgd2F5IEdtaW4gaXMgY2FsY3VsYXRlZCBp biAzNjExLg0KDQpGaW5hbGx5LCBkbyB5b3UgZXhwZWN0IGltcGxlbWVudGF0aW9ucyB0byB1c2Ug Ym90aCB0aGUgVm9JUCBNZXRyaWNzIGJsb2NrIGFuZCB0aGUgQnVyc3QvR2FwIERpc2NhcmQgYmxv Y2sgdG9nZXRoZXIgKGZvciB0aGUgc2FtZSBSVFAgc2Vzc2lvbik/IElmIHNvLCBpcyBpdCBpbXBv cnRhbnQgdGhhdCB0aGUgVGhyZXNob2xkIGluIHRoZSBCdXJzdC9HYXAgRGlzY2FyZCBibG9jayBi ZSBzZXQgdG8gdGhlIHNhbWUgdmFsdWUgYXMgdGhlIEdtaW4gdmFsdWUgaW4gdGhlIFZvSVAgTWV0 cmljcyBibG9jaz8gKElmIHRoZXJlIGFyZSBhbnkgcHJvYmxlbXMgdGhhdCB3b3VsZCBhcmlzZSBp ZiB0aGUgdHdvIHBhcmFtZXRlcnMgd2VyZSBzZXQgdG8gZGlmZmVyZW50IHZhbHVlcywgdGhvc2Ug c2hvdWxkIGJlIG1lbnRpb25lZC4gSWYgdGhlcmUgYXJlIG5vIGFudGljaXBhdGVkIGlzc3VlcyB3 aXRoIHNldHRpbmcgdGhlIHZhbHVlcyBpbmRlcGVuZGVudGx5LCB0aGVuIHRoYXQncyBmaW5lIHRo ZXJlIGlzIG5vIG5lZWQgdG8gc2F5IGFueXRoaW5nIG1vcmUgdGhhbiBpcyBjdXJyZW50bHkgaW4g dGhlIGRvY3VtZW50LikNCg0KW1Fpbl06IFRoZSB0aHJlc2hvbGQgaW4gdGhlIEJ1cnN0IGdhcCBE aXNjYXJkIGJsb2NrIGFuZCBWT0lQIE1ldHJpY3MgQmxvY2sgc2hvdWxkIGJlIHNldCB0byB0aGUg c2FtZSB2YWx1ZSBpZiBib3RoIGJsb2NrcyByZXBvcnQgdGhlIHNhbWUgc3RyZWFtLiBUaGUgdGhy ZXNob2xkIGluIHRoZSBCdXJzdCBnYXAgRGlzY2FyZCBibG9jayBhbmQgVk9JUCBNZXRyaWNzIEJs b2NrIGNhbiBiZSBzZXQgdG8gZGlmZmVyZW50IHZhbHVlcyBpZiBidXJzdCBnYXAgZGlzY2FyZCBi bG9jayBhbmQgVk9JUCBtZXRyaWNzIGJsb2NrIHJlcG9ydCB0aGUgZGlmZmVyZW50IHN0cmVhbSwg d2hpY2ggaXMgaWRlbnRpZmllZCBieSBkaWZmZXJlbnQgU1NSQy4NCklmIGJ1cnN0IGdhcCBibG9j ayBhbmQgVk9JUCBtZXRyaWNzIGJsb2NrIGNhbiByZXBvcnQgdGhlIHNhbWUgc3RyZWFtLCBJIHRo aW5rIGVpdGhlciB3ZSB1c2UgQnVyc3QgR2FwIGJsb2NrIG9yIHdlIHVzZSBWT0lQIG1ldHJpY3Mg YmxvY2ssIHVzdWFsbHkgd2Ugd2lsbCBub3QgdXNlIGJvdGggdG9nZXRoZXIgdG8gcmVwb3J0IHRo ZSBzYW1lIHN0cmVhbS4NClNvIEkgdGhpbmsgaXQgaXMgc2FmZSBmb3Iga2VlcGluZyB3aGF0IGl0 IGlzIGN1cnJlbnRseSBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50IGFzIGl0IGlzLg0KDQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABA43A4C890nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thank Matt= ew for your valuable review.

Please see= my reply inline below.

 = ;

Regards!

-Qin<= /o:p>

=B7=A2=BC=FE=C8=CB: Matthew= Lepinski [mailto:mlepinski.ietf@gmail.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA4=D4=C218=C8=D5 4:22
=CA=D5=BC=FE=C8=CB: secdir@ietf.org; iesg@ietf.org
=B3=AD=CB=CD: draft-ietf-xrblock-rtcp-xr-burst-gap-discard.all@tools.ietf.org
=D6=F7=CC=E2: SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12

 

I have reviewed this docume= nt as part of the security directorate's ongoing effort to review all IETF = documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Do= cument editors and WG chairs should treat these comments just like any othe= r last call comments.

Summary: In my opinion this document is acceptable. I have no concerns with= this document.

 

This document describes a new RTCP block fo= r use in the RTCP eXtended Reporting (XR) framework. The block specified in= this protocol is a companion to the block specified in draft-ietf-xrblock-rtcp-xr-discard. Where I-D.xrblock-rtcp-xr-discard allows a receiver to report the num= ber of packets discarded without being used (played out), this current draf= t allows a receiver to provide additional data regarding the pattern of dis= carded packets. That is, how many of the discarded packets arrived during intervals of high discard rate (i.e.,= intervals of poor quality due to many discards).

 

The document authors claim that= this draft introduces no new security considerations beyond those describe= d in RFC 3611 (RTCP eXtended Reports). I agree with this assessment.

&n= bsp;

[Qin]: Tha= nks.

 = ;

I did have one minor question a= bout Section 3.2. I admit that I am not an RTCP expert, but I was confused = by the description of the Threshold value. The document says that the Thres= hold is calculated in the same way Gmin is calculated in 3611. However, in 3611 it appears that Gmin is a value co= nfigured by the receiver (Recommended to be 16, but can be set to any non-z= ero value the receiver desires.) Am I correct in assuming that Threshold is= also a configured value sent by the receiver? 

&n= bsp;

[Qin]: The= text you are referring to (i.e., Threshold is calculated in the same way G= min is calculated in 3611.) was added corresponding to PM-DIR review. You are right, Gmin is configuration parameter sent by the receive= r. Gmin can be other value than 16, see RFC3611, section 4.7.1

=A1=B0

If the packet spacing is 10 ms = and the Gmin value is the recommended

   value of 16, the burst duration is 12= 0 ms, the burst density 0.33,

   the gap duration 230 ms + 290 ms = =3D 520 ms, and the gap density 0.04.

 = ;

=A1=B1

Maybe the = word =A1=B0calculated=A1=B1 is a little misleading and can be rephrased as = =A1=B0set=A1=B1, i.e.,

The thresh= old is set in the same way Gmin is calculated in 3611.

 = ;

Finally, do you expect implemen= tations to use both the VoIP Metrics block and the Burst/Gap Discard block = together (for the same RTP session)? If so, is it important that the Thresh= old in the Burst/Gap Discard block be set to the same value as the Gmin value in the VoIP Metrics block? (If the= re are any problems that would arise if the two parameters were set to diff= erent values, those should be mentioned. If there are no anticipated issues= with setting the values independently, then that's fine there is no need to say anything more than is currently i= n the document.)

 

[Qin]: = The threshold in the Burst gap Discard block and VOIP Metrics Block should = be set to the same value if both blocks report the same stream. The thresho= ld in the Burst gap Discard block and VOIP Metrics Block can be set to different values if burst gap discard blo= ck and VOIP metrics block report the different stream, which is identified = by different SSRC.

If burs= t gap block and VOIP metrics block can report the same stream, I think eith= er we use Burst Gap block or we use VOIP metrics block, usually we will not= use both together to report the same stream.

So I th= ink it is safe for keeping what it is currently described in the document a= s it is.

 = ;

 

 

--_000_B8F9A780D330094D99AF023C5877DABA43A4C890nkgeml501mbschi_-- From wyaacov@gmail.com Thu Apr 18 02:47:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392D721F8BC5; Thu, 18 Apr 2013 02:47:48 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbPVCB4K5TkQ; Thu, 18 Apr 2013 02:47:47 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id EDFE821F8B9C; Thu, 18 Apr 2013 02:47:46 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id r5so1987391wey.39 for ; Thu, 18 Apr 2013 02:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UEnMhD4R3L66Qf2uuC2C0btppIxGcZx837i4e9h1i+w=; b=bz1NW6I59LpttGwH4M0KI0CsE/tjZ9sU27a/j1b2hdDmXAHxvUlwonRAOMdLlUSheg KDJPsWxYlmih4473IOBR7tSGOuxPb+Q6dIKhadS1D3WDQ47uCnjlNVbGLm9Kjsy597Yz ifho2clbKgJi6oYK+iLNOY88Obi3E8KLHc8GSy1lGD+lgMwg4XGmmftxvvDJnlZdUld7 URkhZrLB/PIBfZQZR5ZhuSNPP0ji3WJoI5+ovDo2khL6D3Kk4961kPrEHYM2Nu0900ty jOv1nuw17s9678E6BAmriXLyKgSPUv5cRIWhf5Q6eTirRlCEy/RkIQGQtLIZFXhFDnEF D2FQ== MIME-Version: 1.0 X-Received: by 10.194.10.129 with SMTP id i1mr1720473wjb.21.1366278466096; Thu, 18 Apr 2013 02:47:46 -0700 (PDT) Received: by 10.194.13.104 with HTTP; Thu, 18 Apr 2013 02:47:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Apr 2013 12:47:46 +0300 Message-ID: From: Yaacov Weingarten To: Tina TSOU Content-Type: multipart/alternative; boundary=047d7b5d5bd8a3a41e04da9f7e19 X-Mailman-Approved-At: Thu, 18 Apr 2013 02:56:08 -0700 Cc: "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir Review of draft-ietf-mpls-tp-ring-protection-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 09:47:48 -0000 --047d7b5d5bd8a3a41e04da9f7e19 Content-Type: text/plain; charset=ISO-8859-1 Tina, hi Thank you for your review, and thank you for the link to the official acronym list. I will incorporate your suggested fixes into the new version of the document that will be uploaded shortly. BR, yaacov On Thu, Apr 18, 2013 at 6:26 AM, Tina TSOU wrote: > Dear all,**** > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments.**** > > ** ** > > It is technically ready, but a few editorial suggestions are below.**** > > ** ** > > Typo, second-last paragraph of Section 1, last sentence:**** > > s/doxument/document/**** > > ** ** > > Editorial suggestion: introduce the abbreviations P2P and P2MP in their > respective bullets at the beginning of Section 1.1. According to the RFC > Editor's list of abbreviations at > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt,**** > > these are not considered well-known, therefore need to be spelled out on > first use. Note the capitalization, per the RFC Editor's list.**** > > ** ** > > In case 3. of Section 1.1, delete "that" after "operator command" in the > first line to make it consistent with the other two cases.**** > > ** ** > > Section 1.2 first paragraph last sentence: the subject of the sentence is > the singular "Requirement", hence s/are/is/ in the final line.**** > > ** ** > > The authors can consider whether they need to spell out LSP and LSR at the > start of Section 1.3. Again, the RFC Editor does not consider these to be > "well-known" abbreviations.**** > > ** ** > > Second paragraph below Figure 1: The last sentence begins: "Coordination > of the switchover ..." I assume the intention here is to indicate that in > this case operation is not so simple as the first sentence indicates. **** > > That should perhaps be signalled by beginning the sentence with: **** > > "However, coordination of the switchover ..."**** > > ** ** > > Sentence before Figure 7: s/complimentary/complementary/**** > > ** ** > > Spell out e2e in the second paragraph below Figure 8, since it is used > once only.**** > > ** ** > > ** ** > > Thank you,**** > > Tina**** > -- Thanx and BR, yaacov *Still looking for new opportunity* --047d7b5d5bd8a3a41e04da9f7e19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Tina, hi
=A0
Thank you for your r= eview, and thank you for the link to the official acronym list.
= =A0
I will incorporate your suggested fixes into the new version = of the document that will be uploaded shortly.
=A0
BR,
yaacov

On Thu, Apr 18, 2013 at 6:26 AM, Tina TSOU <Tina.Tsou.Zout= ing@huawei.com> wrote:

Dear all,<= /u>

I have reviewed this= document as part of the security directorate's ongoing effort to revie= w all IETF documents being processed by the IESG.=A0 These comments were written primarily for the benefit of the security area directors.=A0 = Document editors and WG chairs should treat these comments just like any ot= her last call comments.

=A0

It is technically re= ady, but a few editorial suggestions are below.

=A0

Typo, second-last pa= ragraph of Section 1, last sentence:

=A0 s/doxument/docum= ent/

=A0

Editorial suggestion= : introduce the abbreviations P2P and P2MP in their respective bullets at t= he beginning of Section 1.1. According to the RFC Editor's list of abbreviations at http://www.rfc-editor.org/rfc-style-= guide/abbrev.expansion.txt,

these are not consid= ered well-known, therefore need to be spelled out on first use. Note the ca= pitalization, per the RFC Editor's list.

=A0

In case 3. of Sectio= n 1.1, delete "that" after "operator command" in the fi= rst line to make it consistent with the other two cases.

=A0

Section 1.2 first pa= ragraph last sentence: the subject of the sentence is the singular "Re= quirement", hence s/are/is/ in the final line.

=A0

The authors can cons= ider whether they need to spell out LSP and LSR at the start of Section 1.3= . Again, the RFC Editor does not consider these to be "well-known"= ; abbreviations.

=A0

Second paragraph bel= ow Figure 1: The last sentence begins: "Coordination of the switchover= ..." I assume the intention here is to indicate that in this case operation is not so simple as the first sentence indicates. =

That should perhaps = be signalled by beginning the sentence with:

"However, coord= ination of the switchover ..."

=A0

Sentence before Figu= re 7: s/complimentary/complementary/

=A0

Spell out e2e in the= second paragraph below Figure 8, since it is used once only.=

=A0

=A0

Thank you,=

Tina




--
Thanx = and BR,
yaacov

Still looking for new opport= unity
--047d7b5d5bd8a3a41e04da9f7e19-- From kivinen@iki.fi Thu Apr 18 06:38:27 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DC321F89B0 for ; Thu, 18 Apr 2013 06:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5U5yTDbGd4g for ; Thu, 18 Apr 2013 06:38:27 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1DE21F877A for ; Thu, 18 Apr 2013 06:38:26 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3IDb5lV014334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Apr 2013 16:37:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3IDb4gH029149; Thu, 18 Apr 2013 16:37:04 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20847.63232.553967.723855@fireball.kivinen.iki.fi> Date: Thu, 18 Apr 2013 16:37:04 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 13:38:28 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Rob Austein is next in the rotation. For telechat 2013-04-25 Reviewer LC end Draft Kathleen Moriarty T 2013-04-03 draft-ietf-dnsext-dnssec-algo-signal-10 Eric Rescorla T 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-03 Vincent Roca T 2013-04-08 draft-ietf-pcp-upnp-igd-interworking-08 For telechat 2013-05-16 Eric Rescorla T 2013-04-10 draft-ietf-6renum-gap-analysis-05 Last calls and special requests: Derek Atkins 2013-05-10 draft-sheffer-running-code-04 Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Dan Harkins R2013-04-01 draft-ietf-ipfix-flow-selection-tech-15 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Ondrej Sury 2013-04-23 draft-ietf-manet-olsrv2-mib-06 Carl Wallace 2013-05-07 draft-sparks-genarea-imaparch-06 David Waltermire 2013-05-14 draft-housley-rfc2050bis-01 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-06 Brian Weis 2013-05-01 draft-ietf-ipfix-protocol-rfc5101bis-06 Klaas Wierenga 2013-04-29 draft-ietf-karp-crypto-key-table-07 Nico Williams - draft-ietf-httpbis-p5-range-22 Nico Williams 2013-05-01 draft-ietf-netmod-rfc6021-bis-01 Tom Yu 2013-04-30 draft-ietf-oauth-revocation-07 Glen Zorn 2013-05-14 draft-saintandre-impp-call-info-02 -- kivinen@iki.fi From kathleen.moriarty@emc.com Thu Apr 18 07:18:56 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFC421F8B8F; Thu, 18 Apr 2013 07:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VLwNzoKINQe; Thu, 18 Apr 2013 07:18:56 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id EA1FA21F8F1C; Thu, 18 Apr 2013 07:18:55 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r3IEIqGu019998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Apr 2013 10:18:54 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 18 Apr 2013 10:18:29 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r3IEIRFT028988; Thu, 18 Apr 2013 10:18:27 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Thu, 18 Apr 2013 10:18:27 -0400 From: "Moriarty, Kathleen" To: "draft-ietf-dnsext-dnssec-algo-signal.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Date: Thu, 18 Apr 2013 10:18:25 -0400 Thread-Topic: Sec-Dir review of draft-ietf-dnsext-dnssec-algo-signal-09 Thread-Index: Ac48P5cjrqow/LjWTeWCd8nRS60WGg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24DAA98FA1MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "steve@shinkuro.com" , "scottr.nist@gmail.com" Subject: [secdir] Sec-Dir review of draft-ietf-dnsext-dnssec-algo-signal-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 14:18:57 -0000 --_000_F5063677821E3B4F81ACFB7905573F24DAA98FA1MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document specifies a way for a client to signal its digital signature and hash algorithm knowledge to a cache or server. The intent= is for it to be used by cache or server administrators to track evolving a= lgorithm support. Detail: The draft seems straightforward and is just a method for clients to= notify the server of supported algorithms. The only other attack I can th= ink of, that is not mentioned, would be a denial of service. You may want = to add this to the security considerations and any notes on how it can be p= revented (connections or logs). Best regards, Kathleen --_000_F5063677821E3B4F81ACFB7905573F24DAA98FA1MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of t= he
security area directors.  Document editors and WG chairs should t= reat
these comments just like any other last call comments.
 
Summary: This documen= t specifies a way for a client to signal its digital
   signatur= e and hash algorithm knowledge to a cache or server.  The intent is for it to be used by cache or s= erver administrators to track evolving algorithm support. 
 
 
Detail: The draft seems = straightforward and is just a method for clients to notify the server of su= pported algorithms.  The only other attack I can think of, that is not= mentioned, would be a denial of service.  You may want to add this to the security considerations and any notes on ho= w it can be prevented (connections or logs).
 
Best regards,
Kathleen
 
 
 
 --_000_F5063677821E3B4F81ACFB7905573F24DAA98FA1MX15Acorpemccom_-- From mlepinski.ietf@gmail.com Thu Apr 18 10:24:47 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3124B21F9381; Thu, 18 Apr 2013 10:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[AWL=-3.348, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peeEaJL4fPx0; Thu, 18 Apr 2013 10:24:43 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6754721F8F58; Thu, 18 Apr 2013 10:24:43 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id nd7so1907303qeb.5 for ; Thu, 18 Apr 2013 10:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/ptNsRAVbW6iz1mJPgDO3HLX9RGSei91SWeJPIjc0IA=; b=Ipuq7z2pbzTOZrTRbVPHr8ch/z0JBcWD7Sabcsn3S8jNxqZdXS8nKH0jM8XmxdPI4B uaBVpv5B5iySo1aIMwSVE0T9W+R3l48IuoIOjHtbEQeWZ6Yc0RuGKkCDQRzKVURH//b4 5bzX3+at5VmdHq94BLPMRI7aGQ0iYt8kPdbTQqCTT6TsGXFeHDTB32h56TdPO93PDv5g iMcSYqJklAUCEpa4YumGi76TqveAFZoZi4KWo2DOWby+lRQD+i7f9tnt5n7WSMS9SAHE zJgx46f0SQGiXF7Ti7FogIbWYlL/dR2A70Q/fhgiLNc6D6Iq9BGo+ocqqrbHUVmY3CO8 HIug== MIME-Version: 1.0 X-Received: by 10.229.115.30 with SMTP id g30mr4272605qcq.100.1366305882798; Thu, 18 Apr 2013 10:24:42 -0700 (PDT) Received: by 10.49.81.209 with HTTP; Thu, 18 Apr 2013 10:24:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Apr 2013 13:24:42 -0400 Message-ID: From: Matthew Lepinski To: Qin Wu Content-Type: multipart/alternative; boundary=002354333836cc873104daa5e05d Cc: "draft-ietf-xrblock-rtcp-xr-burst-gap-discard.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] =?gb2312?b?tPC4tDogU2VjRGlyIFJldmlldyBvZiBkcmFmdC1pZXRm?= =?gb2312?b?LXhyYmxvY2stcnRjcC14ci1idXJzdC1nYXAtZGlzY2FyZC0xMg==?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 17:24:47 -0000 --002354333836cc873104daa5e05d Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Thank you for the prompt response. Your explanation makes sense to me. On Thu, Apr 18, 2013 at 2:13 AM, Qin Wu wrote: > Thank Mattew for your valuable review. **** > > Please see my reply inline below.**** > > ** ** > > Regards!**** > > -Qin**** > > *=B7=A2=BC=FE=C8=CB:* Matthew Lepinski [mailto:mlepinski.ietf@gmail.com] > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2013=C4=EA4=D4=C218=C8=D5 4:22 > *=CA=D5=BC=FE=C8=CB:* secdir@ietf.org; iesg@ietf.org > *=B3=AD=CB=CD:* draft-ietf-xrblock-rtcp-xr-burst-gap-discard.all@tools.ie= tf.org > *=D6=F7=CC=E2:* SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-dis= card-12**** > > ** ** > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security ar= ea > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > Summary: In my opinion this document is acceptable. I have no concerns > with this document.**** > > ** ** > > This document describes a new RTCP block for use in the RTCP eXtended > Reporting (XR) framework. The block specified in this protocol is a > companion to the block specified in draft-ietf-xrblock-rtcp-xr-discard. > Where I-D.xrblock-rtcp-xr-discard allows a receiver to report the number = of > packets discarded without being used (played out), this current draft > allows a receiver to provide additional data regarding the pattern of > discarded packets. That is, how many of the discarded packets arrived > during intervals of high discard rate (i.e., intervals of poor quality du= e > to many discards).**** > > ** ** > > The document authors claim that this draft introduces no new security > considerations beyond those described in RFC 3611 (RTCP eXtended Reports)= . > I agree with this assessment.**** > > ** ** > > [Qin]: Thanks.**** > > ** ** > > I did have one minor question about Section 3.2. I admit that I am not an > RTCP expert, but I was confused by the description of the Threshold value= . > The document says that the Threshold is calculated in the same way Gmin i= s > calculated in 3611. However, in 3611 it appears that Gmin is a value > configured by the receiver (Recommended to be 16, but can be set to any > non-zero value the receiver desires.) Am I correct in assuming that > Threshold is also a configured value sent by the receiver? **** > > ** ** > > [Qin]: The text you are referring to (i.e., Threshold is calculated in th= e > same way Gmin is calculated in 3611.) was added corresponding to PM-DIR > review. You are right, Gmin is configuration parameter sent by the > receiver. Gmin can be other value than 16, see RFC3611, section 4.7.1**** > > =A1=B0**** > > If the packet spacing is 10 ms and the Gmin value is the recommended**** > > value of 16, the burst duration is 120 ms, the burst density 0.33,**** > > the gap duration 230 ms + 290 ms =3D 520 ms, and the gap density 0.04.= *** > * > > ** ** > > =A1=B1**** > > Maybe the word =A1=B0calculated=A1=B1 is a little misleading and can be r= ephrased as > =A1=B0set=A1=B1, i.e.,**** > > The threshold is set in the same way Gmin is calculated in 3611.**** > > ** ** > > Finally, do you expect implementations to use both the VoIP Metrics block > and the Burst/Gap Discard block together (for the same RTP session)? If s= o, > is it important that the Threshold in the Burst/Gap Discard block be set = to > the same value as the Gmin value in the VoIP Metrics block? (If there are > any problems that would arise if the two parameters were set to different > values, those should be mentioned. If there are no anticipated issues wit= h > setting the values independently, then that's fine there is no need to sa= y > anything more than is currently in the document.)**** > > ** ** > > [Qin]: The threshold in the Burst gap Discard block and VOIP Metrics Bloc= k > should be set to the same value if both blocks report the same stream. Th= e > threshold in the Burst gap Discard block and VOIP Metrics Block can be se= t > to different values if burst gap discard block and VOIP metrics block > report the different stream, which is identified by different SSRC.**** > > If burst gap block and VOIP metrics block can report the same stream, I > think either we use Burst Gap block or we use VOIP metrics block, usually > we will not use both together to report the same stream. **** > > So I think it is safe for keeping what it is currently described in the > document as it is.**** > > ** ** > > ** ** > > ** ** > --002354333836cc873104daa5e05d Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Thank you for the prompt response. Your explanation m= akes sense to me.


On Thu, Apr 18, 2013 at 2:13 AM, Qin Wu <bill.wu@huawei.com= > wrote:

Thank Matt= ew for your valuable review.

Please see= my reply inline below.

&nb= sp;

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: Matthew= Lepinski [mailto:mlepinski.ietf@gmail.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA4=D4=C218=C8=D5 4:22
=CA=D5=BC=FE=C8=CB: secdir@ietf.or= g; iesg@ietf.org=
=B3=AD=CB=CD: draft-ietf-xrblock-rtcp-xr-burst-gap-discard.al= l@tools.ietf.org
=D6=F7=CC=E2: SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12

 

I have reviewed this docume= nt as part of the security directorate's ongoing effort to review all I= ETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Do= cument editors and WG chairs should treat these comments just like any othe= r last call comments.

Summary: In my opinion this document is acceptable. I have no concerns with= this document.

 

This document describes a new RTCP block fo= r use in the RTCP eXtended Reporting (XR) framework. The block specified in= this protocol is a companion to the block specified in draft-ietf-xrblock-rtcp-xr-discard. Where I-D.xrblock-rtcp-xr-discard allows a receiver to report the num= ber of packets discarded without being used (played out), this current draf= t allows a receiver to provide additional data regarding the pattern of dis= carded packets. That is, how many of the discarded packets arrived during intervals of high discard rate (i.e.,= intervals of poor quality due to many discards).

 

The document authors claim that= this draft introduces no new security considerations beyond those describe= d in RFC 3611 (RTCP eXtended Reports). I agree with this assessment.=

=  

[Qin]: Tha= nks.

&nb= sp;

I did have one minor question a= bout Section 3.2. I admit that I am not an RTCP expert, but I was confused = by the description of the Threshold value. The document says that the Thres= hold is calculated in the same way Gmin is calculated in 3611. However, in 3611 it appears that Gmin is a value co= nfigured by the receiver (Recommended to be 16, but can be set to any non-z= ero value the receiver desires.) Am I correct in assuming that Threshold is= also a configured value sent by the receiver? 

=  

[Qin]: The= text you are referring to (i.e., Threshold is calculated in the same way G= min is calculated in 3611.) was added corresponding to PM-DIR review. You are right, Gmin is configuration parameter sent by the receive= r. Gmin can be other value than 16, see RFC3611, section 4.7.1

“=

If the packet spacing is 10 ms and the Gmin value is the= recommended

 &nbs= p; value of 16, the burst duration is 120 ms, the burst density 0.33,

 &nbs= p; the gap duration 230 ms + 290 ms =3D 520 ms, and the gap density 0.04.

&nb= sp;

”=

Maybe the = word “calculated” is a little misleading and can be rephrased a= s “set”, i.e.,

The thresh= old is set in the same way Gmin is calculated in 3611.=

&nb= sp;

Finally, do you expect implemen= tations to use both the VoIP Metrics block and the Burst/Gap Discard block = together (for the same RTP session)? If so, is it important that the Thresh= old in the Burst/Gap Discard block be set to the same value as the Gmin value in the VoIP Metrics block? (If the= re are any problems that would arise if the two parameters were set to diff= erent values, those should be mentioned. If there are no anticipated issues= with setting the values independently, then that's fine there is no need to say anything more than is current= ly in the document.)

 

[Qin]: = The threshold in the Burst gap Discard block and VOIP Metrics Block should = be set to the same value if both blocks report the same stream. The thresho= ld in the Burst gap Discard block and VOIP Metrics Block can be set to different values if burst gap discard blo= ck and VOIP metrics block report the different stream, which is identified = by different SSRC.

If burs= t gap block and VOIP metrics block can report the same stream, I think eith= er we use Burst Gap block or we use VOIP metrics block, usually we will not= use both together to report the same stream.

So I th= ink it is safe for keeping what it is currently described in the document a= s it is.

&nb= sp;

 

 


--002354333836cc873104daa5e05d-- From kwiereng@cisco.com Fri Apr 19 07:05:24 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98521F8A74; Fri, 19 Apr 2013 07:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoggpHD8GZkU; Fri, 19 Apr 2013 07:05:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D0E0A21F875C; Fri, 19 Apr 2013 07:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2553; q=dns/txt; s=iport; t=1366380324; x=1367589924; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=FdC+aAnrENtFyHY/j86zDpzYZl11Wx8II+89JhvTPj0=; b=K/zrHF0ifPd0b4DpzAQI2njdrGxK76vk7sAvFxl6sCoWWpHNXS4WNrTA Pggrg2tUM5FEYI+xyB3AYPy1MzKAUfNuchrUlfaLgnjumdOG+N96YenX0 tI+o1f8k5XAIXvvr4lqml5RkyfWxPckOEb6pwQBrbkorUU2jtr1X9Fock g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FABNOcVGtJXHA/2dsb2JhbABQgwbBHIEFFnSCIQEEOjIIFwEqFEInBAEaE4d5vTOOdIMeYQOoJYMMgig X-IronPort-AV: E=Sophos;i="4.87,509,1363132800"; d="scan'208";a="200680926" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 19 Apr 2013 14:05:23 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3JE5NVj028161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 14:05:23 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.81]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 09:05:22 -0500 From: "Klaas Wierenga (kwiereng)" To: "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Thread-Topic: draft-ietf-karp-crypto-key-table-07 Thread-Index: AQHOPQbuce+OHU+sDECZBdq2jRPubA== Date: Fri, 19 Apr 2013 14:05:22 +0000 Message-ID: <7E1636E02F313F4BA69A428B314B77C708B0EDEF@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.251] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] draft-ietf-karp-crypto-key-table-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:05:24 -0000 Hi, I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The document is clear and easy to understand. I have a few comments/questio= ns though: * 1 Intro What is conceptual about it? Isn't this supposed to be a specification of t= he format for a real database? At this stage it is unclear to me where the database should reside, under c= ontrol by whom etc. * 2 Conceptual Database Structure introductory paragraph: it is hard to grasp why or why not you want to have= the same key appear twice without understanding what the format of the dat= abase will look like. So I think you should move that part of the first par= agraph to below the column definition. Peers: hmm, so now you have a multivalued column of arbitrary length? What = is the separator? And do you expect normalisation into separate tables to h= appen? Protocol: So here you want only a single security protocol, resulting in ro= ws with the same key but different protocols. Resulting in a more complex l= ookup but no normalisation into separate tables necessary, I'd say best to = choose one solution and stick to it.=20 Sendlifetimestart: I don't see the need for the Z if you already specify th= at the format is UTC * 3 Key Selection and Rollover Do you only want to leave the choice of algorithm/ciphersuite to the client= ? How about including a preference in case of multiple entries for the same= key?=20 I understand the reason to select the latest SendLifeTimeStart, at the same= time, if I want to minimise roll-over I might want to select the key with = the latest AcceptLifeTimeEnd I am wondering whether it makes a lot of sense to separate Send and Accept = LifeTime, I can come up with some constructed examples but I wonder how co= mmon that is, isn't it more typical to stop sending when you don;t want the= peer to accept anymore, i.e. send=3Daccept Lifetime? * 7 Security Considerations I would expect some wording on access to the database, whether the database= is shared etc. The database seems an extremely interesting attack vector t= o me, basically by gaining write access to the database I control the secur= ity policy for the communication between the two peers. Thanks, Klaas From hartmans@painless-security.com Fri Apr 19 07:22:32 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A07C21F919D; Fri, 19 Apr 2013 07:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAJMHn0Nee3q; Fri, 19 Apr 2013 07:22:31 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D0B2B21F90AC; Fri, 19 Apr 2013 07:22:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id DF37D202AC; Fri, 19 Apr 2013 10:22:25 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Su-7LzSh6lh; Fri, 19 Apr 2013 10:22:25 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 19 Apr 2013 10:22:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6874F4499; Fri, 19 Apr 2013 10:22:26 -0400 (EDT) From: Sam Hartman To: "Klaas Wierenga \(kwiereng\)" References: <7E1636E02F313F4BA69A428B314B77C708B0EDEF@xmb-aln-x12.cisco.com> Date: Fri, 19 Apr 2013 10:22:26 -0400 In-Reply-To: <7E1636E02F313F4BA69A428B314B77C708B0EDEF@xmb-aln-x12.cisco.com> (Klaas Wierenga's message of "Fri, 19 Apr 2013 14:05:22 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "secdir@ietf.org" , The IESG , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" Subject: Re: [secdir] draft-ietf-karp-crypto-key-table-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:22:32 -0000 >>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: Klaas> * 1 Intro Klaas> What is conceptual about it? Isn't this supposed to be a Klaas> specification of the format for a real database? No. It's exactly to avoid getting into a discussion of normalization and most of the comments you discuss in your comments on section two that we want this to be conceptual. We don't want to go there because there is no interoperability advantage to specifying things at that level of detail . Klaas> * 2 Conceptual Database Structure Klaas> introductory paragraph: it is hard to grasp why or why not Klaas> you want to have the same key appear twice without Klaas> understanding what the format of the database will look Klaas> like. So I think you should move that part of the first Klaas> paragraph to below the column definition. Klaas> Peers: hmm, so now you have a multivalued column of arbitrary Klaas> length? What is the separator? And do you expect Klaas> normalisation into separate tables to happen? Since we're a conceptual database we don't need to answer any of that:-) To describe the key selection algorithm we need to say it's a set. To have interoperability within protocols we need each protocol to define the format of a member of the set, but *not* how to represent a set as a whole. If we defined a netconf schema we might well need to define how to add and remove members from this set. The natural way to do this will be vendor specific; the way I'd define a IOS-style CLI would be very different than what I'd do for something grabbing configuration from an SQL database. Klaas> Protocol: So here you want only a single security protocol, Klaas> resulting in rows with the same key but different Klaas> protocols. Resulting in a more complex lookup but no Klaas> normalisation into separate tables necessary, I'd say best to Klaas> choose one solution and stick to it. In general, the protocol value is very likely to influence what keys are valid. We also want to strongly discourage the same key being used between protocols. From kwiereng@cisco.com Fri Apr 19 07:48:09 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1644821F8F2E; Fri, 19 Apr 2013 07:48:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfKFuop45iKm; Fri, 19 Apr 2013 07:48:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1808A21F8F1C; Fri, 19 Apr 2013 07:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2819; q=dns/txt; s=iport; t=1366382888; x=1367592488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mEJxhE2zToRj0/qDMCVftV+50h5MdemV/rxkvMjEsdg=; b=Ivti4KFqdLuTYPwiqW+ZzM9lpwIAMnLcO610IWffmDaTcvW4g7oPKb4X QiLv284ZJ1QNDRFH0D9q99I0eNVkYr5O+0qVY5vNj4VxlTO1jUFiKd6c6 FoHzwSXpKiXi9ygye5DPpwoPCPJFKgvqfzjFG1UGfKJ/L7Awj8F+jCb/J U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMhYcVGtJXHB/2dsb2JhbABQgwbBHIEFFnSCHwEBAQMBeQULAgEIIiQyJQIEDgUIE4dzBr0ojnICMQeCZmEDqCWDDIIo X-IronPort-AV: E=Sophos;i="4.87,509,1363132800"; d="scan'208";a="200720172" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 19 Apr 2013 14:48:07 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3JEm74W001414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 14:48:07 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.81]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 09:48:07 -0500 From: "Klaas Wierenga (kwiereng)" To: Sam Hartman Thread-Topic: draft-ietf-karp-crypto-key-table-07 Thread-Index: AQHOPQbuce+OHU+sDECZBdq2jRPubJjdmJ6agABa8oA= Date: Fri, 19 Apr 2013 14:48:07 +0000 Message-ID: <7E1636E02F313F4BA69A428B314B77C708B0F1A3@xmb-aln-x12.cisco.com> References: <7E1636E02F313F4BA69A428B314B77C708B0EDEF@xmb-aln-x12.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.251] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2E524FCA7C13C649B06D85D3755707CB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "secdir@ietf.org" , The IESG , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" Subject: Re: [secdir] draft-ietf-karp-crypto-key-table-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:48:09 -0000 On Apr 19, 2013, at 4:22 PM, Sam Hartman w= rote: >>>>>> "Klaas" =3D=3D Klaas Wierenga (kwiereng) writes= : >=20 >=20 > Klaas> * 1 Intro >=20 > Klaas> What is conceptual about it? Isn't this supposed to be a > Klaas> specification of the format for a real database? >=20 > No. > It's exactly to avoid getting into a discussion of normalization and > most of the comments you discuss in your comments on section two that we > want this to be conceptual. > We don't want to go there because there is no interoperability advantage > to specifying things at that level of detail . >=20 > Klaas> * 2 Conceptual Database Structure >=20 > Klaas> introductory paragraph: it is hard to grasp why or why not > Klaas> you want to have the same key appear twice without > Klaas> understanding what the format of the database will look > Klaas> like. So I think you should move that part of the first > Klaas> paragraph to below the column definition. >=20 > Klaas> Peers: hmm, so now you have a multivalued column of arbitrary > Klaas> length? What is the separator? And do you expect > Klaas> normalisation into separate tables to happen? >=20 > Since we're a conceptual database we don't need to answer any of that:-) hmm ok, I see your point > To describe the key selection algorithm we need to say it's a set. > To have interoperability within protocols we need each protocol to > define the format of a member of the set, but *not* how to represent a > set as a whole. >=20 > If we defined a netconf schema we might well need to define how to add > and remove members from this set. >=20 > The natural way to do this will be vendor specific; the way I'd define a > IOS-style CLI would be very different than what I'd do for something > grabbing configuration from an SQL database. >=20 >=20 > Klaas> Protocol: So here you want only a single security protocol, > Klaas> resulting in rows with the same key but different > Klaas> protocols. Resulting in a more complex lookup but no > Klaas> normalisation into separate tables necessary, I'd say best to > Klaas> choose one solution and stick to it. >=20 > In general, the protocol value is very likely to influence what keys are > valid. > We also want to strongly discourage the same key being used between > protocols. Yes, I understand that argument, but=85.. just like with peers you can argu= e that you don't have to answer any questions about whether you want extra = records or multiple protocols per key in 1 record. It just suffices to say = that you discourage the use of the same key for multiple protocols. Anyway,= I don't feel strongly about this, it just felt inconsistent. Klaas= From kivinen@iki.fi Thu Apr 25 01:54:15 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A9721F8B65 for ; Thu, 25 Apr 2013 01:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1zJWqym+d7P for ; Thu, 25 Apr 2013 01:54:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 81DF021F8539 for ; Thu, 25 Apr 2013 01:54:13 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3P8s9pw010225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Apr 2013 11:54:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3P8s7EN001520; Thu, 25 Apr 2013 11:54:07 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20856.61231.529773.762353@fireball.kivinen.iki.fi> Date: Thu, 25 Apr 2013 11:54:07 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 08:54:15 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dan Harkins is next in the rotation. For telechat 2013-04-25 Reviewer LC end Draft Eric Rescorla T 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-03 Vincent Roca T 2013-04-08 draft-ietf-pcp-upnp-igd-interworking-09 For telechat 2013-05-16 Dave Cridland T 2013-05-06 draft-ietf-dhc-triggered-reconfigure-05 Shawn Emery T 2013-05-03 draft-ietf-netmod-interfaces-cfg-10 Tobias Gondrom T 2013-05-03 draft-ietf-netmod-ip-cfg-09 Steve Hanna T 2013-05-08 draft-ietf-trill-fine-labeling-06 Dan Harkins TR2013-04-01 draft-ietf-ipfix-flow-selection-tech-16 Eric Rescorla T 2013-04-10 draft-ietf-6renum-gap-analysis-05 Nico Williams T 2013-05-01 draft-ietf-netmod-rfc6021-bis-01 For telechat 2013-05-30 Rob Austein T 2013-05-06 draft-ietf-bmwg-imix-genome-04 Last calls and special requests: Derek Atkins 2013-05-10 draft-sheffer-running-code-04 Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-05-06 draft-ietf-geopriv-held-measurements-07 Donald Eastlake 2013-05-03 draft-ietf-geopriv-relative-location-04 Phillip Hallam-Baker - draft-ietf-spfbis-4408bis-14 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Ondrej Sury 2013-04-23 draft-ietf-manet-olsrv2-mib-06 Carl Wallace 2013-05-07 draft-sparks-genarea-imaparch-06 David Waltermire 2013-05-14 draft-housley-rfc2050bis-01 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-06 Brian Weis 2013-05-01 draft-ietf-ipfix-protocol-rfc5101bis-06 Nico Williams - draft-ietf-httpbis-p5-range-22 Tom Yu 2013-04-30 draft-ietf-oauth-revocation-07 Glen Zorn 2013-05-14 draft-saintandre-impp-call-info-02 -- kivinen@iki.fi From vincent.roca@inria.fr Thu Apr 25 02:01:07 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35F421F93EE; Thu, 25 Apr 2013 02:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.449 X-Spam-Level: X-Spam-Status: No, score=-109.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZlT5VsBjacK; Thu, 25 Apr 2013 02:01:06 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id B6B4521F86CA; Thu, 25 Apr 2013 02:01:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,548,1363129200"; d="scan'208,217";a="12155568" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.103]) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 25 Apr 2013 11:01:04 +0200 From: Vincent Roca Content-Type: multipart/alternative; boundary=Apple-Mail-3--121276503 Date: Thu, 25 Apr 2013 11:01:03 +0200 Message-Id: To: IESG , secdir@ietf.org, draft-ietf-pcp-upnp-igd-interworking.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [secdir] Secdir review of draft-ietf-pcp-upnp-igd-interworking-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 09:01:07 -0000 --Apple-Mail-3--121276503 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. -- 1- Authors refer to [IGD2] (which is produced by UPnP), saying that the = authorization framework defined there SHOULD be used. However I haven't found the description of = such a framework in [IGD2] (I've looked at the Content Table and searched "Authorization" = keyword). Can you be more explicit in your reference? Additionally [IGD2] says (p.10): "IGD 2 introduces access control features. [IGD2] RECOMMENDS = access control requirements and authorization levels to be applied by default. However, = devices MAY choose a different security policy," I do not understand the consequences of devices choosing a different = security policy, and how it relates to your I-D. then, same page: "In the 2-box model, where the control point is in the same = device that desires to receive communication through the NAT, [IGD2] RECOMMENDS that access = control is not needed. But in the 3-box model, where the control point is configuring NAT port = mappings for a third device, [IGD2] RECOMMENDS that authentication and authorization is = used." It's not clear to me in which case of [IGD2] your I-D corresponds to. 2- It is said: "Means to prevent a malicious user from creating mappings on behalf of a = third party must be enabled as discussed in Section 13.1 of [I-D.ietf-pcp-base]." What are the means mentioned? If I look at 13.1 of this reference, I see = that the THIRD_PARTY option "MUST NOT be implemented or used" unless the network is trusted, and the = example of trusted network is the case where there's an ACL on PCP client/PCP server/network.=20 Can you be more explicit in your recommendations? 3- You reference [Sec-DCP] but do not provide the URL, nor version = number. Since this is an external document, it would be great. Also, the one I found = (http://upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1-Service.pdf accessible from page http://upnp.org/specs/gw/deviceprotection1/) is = from Feb. 2011, not 2009. 4- I don't see any threat model in this Security Discussions section. There's good one in [I-D.ietf-pcp-base], but this is a different = protocol, deployed differently. What can we say for the IWF itself? There are some elements in this section, some pointers, but I don't get = any clear idea of the situation. -- Otherwise, regardless of any security consideration: 5- Fig. 1 mentions UPnP control point. Other figures of Section 3 = mention IGD control point. Is it the same? If yes, can you harmonize? This figure also remains somewhat mysterious to me. Can you add some = more text at the end of the first paragraph of Introduction. And why does this figure appear = after the "two configurations" discussion? 6- Introduction: you mention that two configurations are possible. Do = you consider both of them? What are the consequences of these two configurations on IWF? As such, reading this introduction did not help me so much understanding = the proposal. Section 3 is much better from that point of view. Cheers, Vincent= --Apple-Mail-3--121276503 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
1- = Authors refer to [IGD2] (which is produced by UPnP), saying that the = authorization framework
in = [IGD2] (I've looked at the Content Table and searched "Authorization" = keyword). Can you be
more = explicit in your reference?
Additionally =  [IGD2] says (p.10):
        and = authorization levels to be applied by default. However, devices MAY = choose a different
I do not understand the = consequences of devices choosing a different security policy, and how = it
relates to your I-D.

then, same page:
        "In = the 2-box model, where the control point is in the same device that = desires to receive
        the = 3-box model, where the control point is configuring NAT port mappings = for a third device,
It's = not clear to me in which case of [IGD2] your I-D corresponds = to.


2- It is said:
"Means to prevent a malicious = user from creating mappings on behalf of a third party must be = enabled
as discussed in Section = 13.1 of [I-D.ietf-pcp-base]."
What = are the means mentioned? If I look at 13.1 of this reference, I see that = the THIRD_PARTY option
"MUST = NOT be implemented or used" unless the network is trusted, and the = example of trusted network
is = the case where there's an ACL on PCP client/PCP = server/network. 
Can = you be more explicit in your recommendations?


3- You reference [Sec-DCP] but = do not provide the URL, nor version number. Since this is an = external
document, it would = be great.
=
accessible from page http://upnp.org/specs= /gw/deviceprotection1/) is from Feb. 2011, not 2009.


4- I don't see any threat model = in this Security Discussions section.
There's good one in [I-D.ietf-pcp-base], but this = is a different protocol, deployed differently.
What can we say for the IWF = itself?
There are some elements = in this section, some pointers, but I don't get any clear idea of = the
situation.


--


5- Fig. 1 mentions UPnP control = point. Other figures of Section 3 mention IGD control point.
Is it the same? If yes, can you = harmonize?
This figure also remains = somewhat mysterious to me. Can you add some more text at the end = of
the first paragraph of = Introduction. And why does this figure appear after the "two = configurations"
6- Introduction: you = mention that two configurations are possible. Do you consider both of = them?
What are the = consequences of these two configurations on IWF?

As such, reading this = introduction did not help me so much understanding the proposal. Section = 3
is much better from that point of = view.

Cheers,

  V= incent
= --Apple-Mail-3--121276503-- From glenzorn@gmail.com Thu Apr 25 04:38:31 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA5621F95FB; Thu, 25 Apr 2013 04:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37YXFnha2+re; Thu, 25 Apr 2013 04:38:30 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD41721F95F9; Thu, 25 Apr 2013 04:38:30 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id lf10so1815390pab.32 for ; Thu, 25 Apr 2013 04:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; bh=SCc2213nFYU+e96DJK0SbBwPW8GTf2p9p8obJox/obU=; b=YSSwae1atVRcdnkAP/hfZAuDCMkDPu5veDJhkrYkFz8uF6vVQi9/TUAtQSN7TfyJ77 KMs3RZKaI4pOfuOdOjID/yB5naz2gadJuEyZ4sPKk9CKRHomOQAXUR8N+x0e0uJd3NfT JIX1iF+9teDVdBEn/SEx1JuVy12bSlJ17e9yJS+o3HkYqUAPMHdv5jjRs3H617k9jpjo pYTQYEIaXfGU8IaZm/MYc9tfpPHI662Yokt5pxdGgkZgO/Aj/omr1K7izujkRk2HqCiw 2w+aEUTsZe8Az6eQfT87WTVjBZOVqlGtinhsdJs9bocapZTWcP3wOJOIlZMoafVQS+RE BSjg== X-Received: by 10.66.220.197 with SMTP id py5mr24911689pac.86.1366889910508; Thu, 25 Apr 2013 04:38:30 -0700 (PDT) Received: from [192.168.0.104] (ppp-124-122-172-147.revip2.asianet.co.th. [124.122.172.147]) by mx.google.com with ESMTPSA id mm9sm7017077pbc.43.2013.04.25.04.38.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 04:38:29 -0700 (PDT) Message-ID: <517915B1.3050306@gmail.com> Date: Thu, 25 Apr 2013 18:38:25 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-saintandre-impp-call-info.all@tools.ietf.org, The IESG , "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-saintandre-impp-call-info-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 11:38:31 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. No problems, ready for publication. From mohamed.boucadair@orange.com Fri Apr 26 01:43:50 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9737F21F97E0; Fri, 26 Apr 2013 01:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90POjy6GPXtk; Fri, 26 Apr 2013 01:43:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 07B6421F96A8; Fri, 26 Apr 2013 01:43:45 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B05BE324762; Fri, 26 Apr 2013 10:43:44 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 904824C017; Fri, 26 Apr 2013 10:43:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 26 Apr 2013 10:43:44 +0200 From: To: Vincent Roca , IESG , "secdir@ietf.org" , "draft-ietf-pcp-upnp-igd-interworking.all@tools.ietf.org" Date: Fri, 26 Apr 2013 10:43:41 +0200 Thread-Topic: Secdir review of draft-ietf-pcp-upnp-igd-interworking-07 Thread-Index: Ac5Bk3OFDBA0LMDhTwis8wX5lfVuFwAw5dvg Message-ID: <94C682931C08B048B7A8645303FDC9F36EC9B4978E@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EC9B4978EPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.25.35414 Subject: Re: [secdir] Secdir review of draft-ietf-pcp-upnp-igd-interworking-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 08:43:50 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EC9B4978EPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Vincent, Thank you for the review. Please see inline. Cheers, Med De : Vincent Roca [mailto:vincent.roca@inria.fr] Envoy=E9 : jeudi 25 avril 2013 11:01 =C0 : IESG; secdir@ietf.org; draft-ietf-pcp-upnp-igd-interworking.all@tools= .ietf.org Cc : Vincent Roca Objet : Secdir review of draft-ietf-pcp-upnp-igd-interworking-07 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. -- 1- Authors refer to [IGD2] (which is produced by UPnP), saying that the aut= horization framework defined there SHOULD be used. However I haven't found the description of su= ch a framework in [IGD2] (I've looked at the Content Table and searched "Authorization" ke= yword). Can you be more explicit in your reference? [Med] This basically refers to access and authorization levels discussed in= [IGD2]. Perhaps, "Framework" is confusing here. What about tis change: OLD: "The IGD:2 authorization framework SHOULD be used [IGD2]." NEW: "The IGD:2 access and authorization considerations discussed in [IGD2] SH= OULD be taken into account." Additionally [IGD2] says (p.10): "IGD 2 introduces access control features. [IGD2] RECOMMENDS access= control requirements and authorization levels to be applied by default. However, devices= MAY choose a different security policy," I do not understand the consequences of devices choosing a different securi= ty policy, and how it relates to your I-D. then, same page: "In the 2-box model, where the control point is in the same device = that desires to receive communication through the NAT, [IGD2] RECOMMENDS that access contro= l is not needed. But in the 3-box model, where the control point is configuring NAT port ma= ppings for a third device, [IGD2] RECOMMENDS that authentication and authorization is used." It's not clear to me in which case of [IGD2] your I-D corresponds to. [Med] Both cases are covered for IGD:2. For the IGD:1 case, only the 3-box = model is recommended: "When only IGD:1 is available, operation on the behalf of a third party SHOULD NOT be allowed. " 2- It is said: "Means to prevent a malicious user from creating mappings on behalf of a th= ird party must be enabled as discussed in Section 13.1 of [I-D.ietf-pcp-base]." What are the means mentioned? If I look at 13.1 of this reference, I see th= at the THIRD_PARTY option "MUST NOT be implemented or used" unless the network is trusted, and the ex= ample of trusted network is the case where there's an ACL on PCP client/PCP server/network. Can you be more explicit in your recommendations? [Med] I made the following change : OLD: This document defines a procedure to create PCP mappings for third party devices belonging to the same subscriber. Means to prevent a malicious user from creating mappings on behalf of a third party must be enabled as discussed in Section 13.1 of [I-D.ietf-pcp-base]. NEW: This document defines a procedure to create PCP mappings for third party devices belonging to the same subscriber. Means to prevent a malicious user from creating mappings on behalf of a third party must be enabled as discussed in Section 13.1 of [I-D.ietf-pcp-base]. In particular, THIRD_PARTY option MUST NOT be enabled unless the network on which the PCP messages are to be sent is fully trusted. For example if access control lists are installed on the PCP client, PCP server, and the network between them, so those ACLs allow only communications from a trusted PCP client to the PCP server. Better? 3- You reference [Sec-DCP] but do not provide the URL, nor version number. = Since this is an external document, it would be great. Also, the one I found (http://upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1= -Service.pdf accessible from page http://upnp.org/specs/gw/deviceprotection1/) is from F= eb. 2011, not 2009. [Med] Fixed. Thanks. 4- I don't see any threat model in this Security Discussions section. There's good one in [I-D.ietf-pcp-base], but this is a different protocol, = deployed differently. What can we say for the IWF itself? [Med] This document does not define a new protocol. [I-D.ietf-pcp-base] dis= cusses security considerations without any assumption on how PCP messages a= re triggered: user interface, application, etc. This document focuses on th= e particular case where PCP messages are triggered by IGD ones. As such thi= s document does not change the threat model discussed in the base PCP speci= fication. For the UPnP IGD leg, we provided some security recommendations d= efined by the UPnP Forum. There are some elements in this section, some pointers, but I don't get any= clear idea of the situation. -- Otherwise, regardless of any security consideration: 5- Fig. 1 mentions UPnP control point. Other figures of Section 3 mention I= GD control point. Is it the same? If yes, can you harmonize? [Med] Fixed. Only 'IGD Control Point' is used now. This figure also remains somewhat mysterious to me. Can you add some more t= ext at the end of the first paragraph of Introduction. And why does this figure appear after = the "two configurations" discussion? [Med] The figure is now positioned just after the first paragraph. 6- Introduction: you mention that two configurations are possible. Do you c= onsider both of them? What are the consequences of these two configurations on IWF? [Med] Both configurations are in scope. I made the following change to make= this explicit: OLD: Two configurations are considered: o No NAT function is embedded in the IGD. This is required for instance in DS-Lite or NAT64 deployments; o The IGD embeds a NAT function. NEW: Two configurations are considered within this document: o No NAT function is embedded in the IGD (Section 5.4). This is required for instance in DS-Lite or NAT64 deployments; o The IGD embeds a NAT function (Section 5.5). As such, reading this introduction did not help me so much understanding th= e proposal. Section 3 is much better from that point of view. Cheers, Vincent --_000_94C682931C08B048B7A8645303FDC9F36EC9B4978EPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Vincent,

 

Thank you for the review.

=  

Please see inline.<= /span>

Cheers,

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4= .0pt'>

De : Vincent Roca [mailto:vince= nt.roca@inria.fr]
Envoy=E9 : jeudi 25 avril 2013 11:01
<= b>=C0 : IESG; secdir@ietf.org; draft-ietf-pcp-upnp-igd-interworkin= g.all@tools.ietf.org
Cc : Vincent Roca
Objet : Secdir review of draft-ietf-pcp-upnp-igd-interworking-07

 

Hello,

I have reviewed this document as part of the security di= rectorate's
ongoing effort to review all IETF documents being processed = by the
IESG.  These comments were written primarily for the benefit= of the
security area directors. Document editors and WG chairs should t= reat
these comments just like any other last call comments.

--

 

=

1- Authors refer to [IGD2] (which is produce= d by UPnP), saying that the authorization framework

defined there SHOULD be used. However I haven't foun= d the description of such a framework

in [IGD2] (I've looked at the Content Table and searched "Aut= horization" keyword). Can you be

more explicit in your reference?

 

[Med] This basically refers to = access and authorization levels discussed in [IGD2]. Perhaps, “Framew= ork” is confusing here. What about tis change:
 
OLD:<=
/pre>
 “The IGD:2 authorization framework SHOULD be used [IGD2].” 
&=
nbsp;
NEW=
:
&#=
8220;The IGD:2 access and authorization considera=
tions discussed in [IGD2] SHOULD be taken=
 into account.”
 

Additionally  [IGD2] says (= p.10):

        "IGD 2 introduces access contro= l features. [IGD2] RECOMMENDS access control requirements

        and authorization = levels to be applied by default. However, devices MAY choose a different

        sec= urity policy,"

I do not = understand the consequences of devices choosing a different security policy= , and how it

relates to your = I-D.

 

then, same page:

        "In the 2-box model, wher= e the control point is in the same device that desires to receive

        communicat= ion through the NAT, [IGD2] RECOMMENDS that access control is not needed. B= ut in

      &n= bsp; the 3-box model, where the control point is configuring NAT port mappi= ngs for a third device,

 = ;       [IGD2] RECOMMENDS that authentication and authorizat= ion is used."

It's not c= lear to me in which case of [IGD2] your I-D corresponds to.

<= p class=3DMsoNormal>[Med] Both cases are covered for IGD:2. For = the IGD:1 case, only the 3-box model is recommended:

<= p class=3DMsoNormal> 

“When only=

=A0=A0 IGD:1 is available, =
operation on the behalf of a third party SHOULD
=A0=A0 NOT be allowed.

”

 

2= - It is said:

"Means to = prevent a malicious user from creating mappings on behalf of a third party = must be enabled

as discussed = in Section 13.1 of [I-D.ietf-pcp-base]."

What are the means mentioned? If I look at 13.1 of this re= ference, I see that the THIRD_PARTY option

"MUST NOT be implemented or used" unless the networ= k is trusted, and the example of trusted network

<= p class=3DMsoNormal>is the case where there's an ACL on PCP client/PCP serv= er/network. 

Can you be = more explicit in your recommendations?

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New";color= :#1F497D'>[Med] I made the following change :

 

OLD:

=A0=A0 This=
 document defines a procedure to create PCP mappings for third
=A0=A0 party devices belonging to the sa=
me subscriber.=A0 Means to prevent a
=A0=A0 malicious user from creating mappings on behalf of a third =
party must
=A0=A0 be enabled=
 as discussed in Section 13.1 of [I-D.ietf-pcp-base].

 

NEW:

 

=A0=A0 This document defines a procedure to create PCP= mappings for third

=A0=A0 party devices belonging to the same subsc= riber.=A0 Means to prevent a

=A0=A0 malicious user from creating map= pings on behalf of a third party must

=A0=A0 be enabled as discussed= in Section 13.1 of [I-D.ietf-pcp-base].=A0 In

=A0=A0 particular, TH= IRD_PARTY option MUST NOT be enabled unless the network

=A0=A0 on wh= ich the PCP messages are to be sent is fully trusted.=A0 For

=A0=A0 = example if access control lists are installed on the PCP client, PCP

=A0=A0 server, and the network between them, so those ACLs allow only=

=A0=A0 communications from= a trusted PCP client to the PCP server.

 

Better?

 

 

3-= You reference [Sec-DCP] but do not provide the URL, nor version number. Si= nce this is an external

docum= ent, it would be great.

accessible= from page http://u= pnp.org/specs/gw/deviceprotection1/) is from Feb. 2011, not 2009.<= /o:p>

 

[Med] Fixed. Thanks.<= /span>

 

<= p class=3DMsoNormal>4- I don't see any threat model in this Security Discus= sions section.

There's good o= ne in [I-D.ietf-pcp-base], but this is a different protocol, deployed diffe= rently.

What can we say for t= he IWF itself?

[Med] This do= cument does not define a new protocol. [I-D.ietf-pcp-base] discusses securi= ty considerations without any assumption on how PCP messages are triggered:= user interface, application, etc. This document focuses on the particular = case where PCP messages are triggered by IGD ones. As such this document do= es not change the threat model discussed in the base PCP specification. For= the UPnP IGD leg, we provided some security recommendations defined by the= UPnP Forum.

&nbs= p;

There are some elements = in this section, some pointers, but I don't get any clear idea of the<= /o:p>

situation.

 

--

 

Otherwise, regardless of any security considera= tion:

 

5- Fig. 1 mentions UPnP control point. Other = figures of Section 3 mention IGD control point.

Is it the same? If yes, can you harmonize?

[Med] Fixed. Only ‘IGD Control Point= ’ is used now.

 

This figure al= so remains somewhat mysterious to me. Can you add some more text at the end= of

the first paragraph of In= troduction. And why does this figure appear after the "two configurati= ons"

discussion?

[Med] The figure is now positioned j= ust after the first paragraph.

 

6- Introduction: you mention that two configurations are possi= ble. Do you consider both of them?

What are the consequences of these two configurations on IWF?

[Med] Both configurations are in sco= pe. I made the following change to make this explicit:

 

OLD:

 
=A0=A0 Two configurations are considered:
 
=A0=A0 o=A0 No NAT function is embedded in the IGD.=A0 This i=
s required for
=A0=A0=A0=A0=
=A0 instance in DS-Lite or NAT64 deployments;
<=
span lang=3DEN-US>=A0=A0 o=A0 The IGD embeds a NAT function.

 

NEW:

 

=A0=A0 Two configurations are considered within this= document:

 

=A0=A0 o=A0 No NAT function is embedded in = the IGD (Section 5.4).=A0 This is

=A0=A0=A0=A0=A0 required for insta= nce in DS-Lite or NAT64 deployments;

=A0=A0 o=A0 The IGD embeds a NAT function (Section 5.5).

&= nbsp;

As such, reading this= introduction did not help me so much understanding the proposal. Section 3=

is much better from t= hat point of view.

 

Cheers,=

  Vincent

= --_000_94C682931C08B048B7A8645303FDC9F36EC9B4978EPUEXCB1Bnante_-- From new-work-bounces@ietf.org Fri Apr 26 09:17:32 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE92921F99F1; Fri, 26 Apr 2013 09:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1366993052; bh=bGcIZo8/KIPT45MYg+85fZS0P8P0byfvr9U4twspgP8=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=rKrqRPy/x7u6CgASRGZl1lVj6eqa1drjgO0G3Aw2Wqq22lkCuN5YwEfRDFe8PHl1T HW9/M+lYLruOzXHter55X0inXJL3jkFABnU8kGUvEMZEsS31VWKkjNBjUIXS3xh6mP SiDDBWwPoHmtBcar53YIy7wUuw3JF6RQc7sw8Mr4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4134321F99F9; Fri, 26 Apr 2013 09:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO63X4DlAnIq; Fri, 26 Apr 2013 09:17:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 739B621F99EB; Fri, 26 Apr 2013 09:17:31 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426161731.17881.23403.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 09:17:31 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 26 Apr 2013 09:33:17 -0700 Subject: [secdir] [new-work] WG Review: Forwarding and Control Element Separation (forces) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:17:33 -0000 The Forwarding and Control Element Separation (forces) working group in the Routing Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-05-06. Forwarding and Control Element Separation (forces) ------------------------------------------------ Current Status: Active Working Group Chairs: Jamal Hadi Salim Assigned Area Director: Adrian Farrel Mailing list Address: forces@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/forces Archive: http://www.ietf.org/mail-archive/web/forces/ Charter of Working Group: The ForCES working group has created a framework, requirements, a solution protocol, a logical function block library, and other associated documents in support of Forwarding and Control Element Separation. Drawing on the experience gained from developing the standards and from many efforts using this architecture, the ForCES working group is now working on a set of additions to the model, the protocol, and the libraries. The following 5 work items are the chartered tasks of this working group: o Extensions to Model and Protocol This work is to address a set of extensions to the base model and protocol resulting in updates to RFCs 5810 and 5812. This effort will produce 2 Standards Track documents (one for the model and another for the protocol). The model extensions will: 1. Allow complex metadata 2. Allow optional default values for datatypes 3. Allow optional access-type for datatypes inside complex components 4. Define new base type: Bitmap 5. Define new events to monitor states. The protocol extensions will: 1. Support table range query 2. Support table append 3. Define additional return codes to reduce ambiguity 4. Define data packing rule for bitmap datatype. o Inter-FE Connectivity ForCES processing is often spread across multiple Forwarding Elements (FEs). The original framework identified the interface between FEs as the "Fi" reference point. Protocol and Logigal Function Block (LFB) mechanisms to carry metadata across the Fi interface are needed. This effort will produce a standards track doument defining the protocol on the wire to address this need, and the LFBs used to represent the Interfaces for sending and receiving such information. It is expected that this work will draw heavily on existing protocol and LFB definitions. o Parallelization An FE can implement an LFB chain with parallelization, but the currently-defined mechanism has no means to represent when synchronization is needed, or to allow the CE to specify where it believes such parallelism is useful. This work item will produce a single standards track document to improve the handling of this case. o Subsidiary Management Deployment experience has demonstrated the value of using ForCES to control the Forwarding Element Manager (FEM) by creating an LFB to represent its function using the same encoding rules as for any other LFB. This allows it to be controlled by the same Control Element (CE). This work item assumes the presence of an initially booted FE whose configuration could then be updated at runtime via an FEM LFB for runtime config purposes (e.g., by adding a new CE and its associated IP address). This work item can also be useful in addressing control of virtual FEs where individual FEM Managers can be addressed to control the creation, configuration, and resource assignment of such virtual FEs within a physical FE. This work would result in a standards track LFB FEM library RFC. In addition to the specific work items listed above, the working group will allow discussions and review work of how to use ForCES to model topics of interest to Network Function Virtualization, I2RS, or OpenFlow. It is understood that the primary responsibility for such documents lives with other working groups, individual contributions, or other standards bodies. == Goals and Milestones == September 2013 Request for Publication of Standards Track document specifying model changes September 2013 Request for Publication of Standards Track document specifying protocol changes February 2014 Request for publication of Subsidiary management LFB March 2014 Request for publication of Inter-FE LFB March 2014 Request for publication of parallelization LFBs April 2014 Recharter or shutdown _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From hallam@gmail.com Fri Apr 26 09:58:50 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C714121F99BE; Fri, 26 Apr 2013 09:58:50 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liQ+kxeTMhFU; Fri, 26 Apr 2013 09:58:50 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A050521F99C5; Fri, 26 Apr 2013 09:58:49 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id t11so555185wey.9 for ; Fri, 26 Apr 2013 09:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=qi+INK0B8Dqg4bCusedTxQ0g7jYzw6xId35rZ1TuZnk=; b=Nq4owlvKWSRVbK84iExMU8yq7ZBdOT4w0zi8RhHseNGSpT3C1rMNvTsNK9krIFNrmJ BWPmLjoYsxEgGFN3o/zP0MwD6H5vPJOt3SGs5NT2vbhnQ5Fwp8IFfDKDAve8CtGbacXq OrBhD8Qe3yvrpY03/WJs1cvGlFU4mZwA4Iou5bpjF0byuGr5wOiEcfenRPnI32ND6KBn uVWTF4IsI8MV0O9SRDNyAXaEQfxSXEEy8NMgqpc2d7dQH2R7ghdaEVnWt+qz2mtntce8 C6GgbyzcaKCQn/Vjp9NiGqPZQckK5N3mWiAvxuiuTsk790N4xVQf6mDQvc7GH+/9siaI 1CUQ== MIME-Version: 1.0 X-Received: by 10.194.173.228 with SMTP id bn4mr29091899wjc.20.1366995528813; Fri, 26 Apr 2013 09:58:48 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 26 Apr 2013 09:58:48 -0700 (PDT) Date: Fri, 26 Apr 2013 12:58:48 -0400 Message-ID: From: Phillip Hallam-Baker To: "iesg@ietf.org" , draft-ietf-spfbis-4408bis.all@tools.ietf.org, "secdir@ietf.org" Content-Type: multipart/alternative; boundary=089e0122e8dce7948204db467214 Subject: [secdir] draft-ietf-spfbis-4408bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:58:50 -0000 --089e0122e8dce7948204db467214 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is clear and describes the SPF mechanism effectively. The only quibble that I could find is that repeated mentions are made of limiting the number of 'DNS queries' without specifying whether these are individual queries or recursive. The count will come out rather differently if looking up TXT/x.example.com counts as one lookup or three. I think it is reasonably clear that this is one but could not find an explicit statement to that effect. On the security side, the document addresses all the mail issues that I can remember at this point and rather more besides. I think we have reached the point of diminishing returns. The document provides a clear enough warning to people configuring SPF records as to the consequences of getting it wrong which is the main concern. The filtering services will know their business well enough to minimize false positives. Hopefully the email infrastructure will evolve over time towards concentrating on the more policy friendly approaches and it will be possible to simplify the mechanism at a future date. -- Website: http://hallambaker.com/ --089e0122e8dce7948204db467214 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dir= ectorate's
ongoing effort to review all IETF documents being= processed by the
IESG. =A0These comments were written primarily for the benefit of the
security area directors. =A0Document editors and WG chairs should treat
these comments just like any other last call comments.


The document is clear and des= cribes the SPF mechanism effectively. The only quibble that I could find is= that repeated mentions are made of limiting the number of 'DNS queries= ' without specifying whether these are individual queries or recursive.= The count will come out rather differently if looking up TXT/x.example.com counts as one lookup or three. I thin= k it is reasonably clear that this is one but could not find an explicit st= atement to that effect.

On the security side, the document addresse= s all the mail issues that I can remember at this point and rather more bes= ides.=A0

I think we have reached the p= oint of diminishing returns.

The document provides a clear enough warnin= g to people configuring SPF records as to the consequences of getting it wr= ong which is the main concern. The filtering services will know their busin= ess well enough to minimize false positives.

Hopefully the email infrastructure will evo= lve over time towards concentrating on the more policy friendly approaches = and it will be possible to simplify the mechanism at a future date.


--
Website: http://hallambaker.com/
--089e0122e8dce7948204db467214-- From sm@elandsys.com Fri Apr 26 10:25:40 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207E621F984C; Fri, 26 Apr 2013 10:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZS0lfGetaLsE; Fri, 26 Apr 2013 10:25:39 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF7C21F9832; Fri, 26 Apr 2013 10:25:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.115]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3QHPHoC017907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Apr 2013 10:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366997131; bh=T0/tmdL/jbVwndZ5x3yxecmWKIGXhkyzpLa+ZF8c7LA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=b9mVwHoP9BAGFGQJsbx9e/JKYZbE26jO2IjPr22DuLCAYo2S5s/2+Ns8CGZefIVeN kWuj2NHnhsa8YT7XE1SXCc2zk140n2Xj05MiD1dBuwvfFvYDxbdBEy+/LIDsm04nL5 9nl+tESEvRUfwAo4u03jS4nNOpXkkCys9cnB9rI0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366997131; i=@elandsys.com; bh=T0/tmdL/jbVwndZ5x3yxecmWKIGXhkyzpLa+ZF8c7LA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TUIfTDRBPDH/WPh4T/2p+D1Mv4u1Y1fqXMWoAd651eLcNKtBRc5Rzhuel8MQvLnWH n45xhxTjU4OeX6yX5fwCenCIZDcKWiw0QWJ3Bj1+PifdvZchN7s4aRSV2wfeqjSHk4 OlDj3FK8fGyQosjwBKE51QbB1nFSnaUacBlQH200= Message-Id: <6.2.5.6.2.20130426101142.0c89d698@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Apr 2013 10:16:35 -0700 To: Phillip Hallam-Baker From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Sun, 28 Apr 2013 08:09:59 -0700 Cc: draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-spfbis-4408bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 17:25:40 -0000 Hi Phillip, At 09:58 26-04-2013, Phillip Hallam-Baker wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > > >The document is clear and describes the SPF mechanism effectively. >The only quibble that I could find is that repeated mentions are >made of limiting the number of 'DNS queries' without specifying >whether these are individual queries or recursive. The count will >come out rather differently if looking up >TXT/x.example.com counts as one lookup or >three. I think it is reasonably clear that this is one but could not >find an explicit statement to that effect. > >On the security side, the document addresses all the mail issues >that I can remember at this point and rather more besides. > >I think we have reached the point of diminishing returns. > >The document provides a clear enough warning to people configuring >SPF records as to the consequences of getting it wrong which is the >main concern. The filtering services will know their business well >enough to minimize false positives. > >Hopefully the email infrastructure will evolve over time towards >concentrating on the more policy friendly approaches and it will be >possible to simplify the mechanism at a future date. Thanks for the review. I'll wait for the WGLC comments to be addressed before getting back to you about the quibble mentioned above. Regards, S. Moonesamy (as document shepherd) From tlyu@mit.edu Mon Apr 29 22:11:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D9D21F99E4; Mon, 29 Apr 2013 22:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApqjQ280JoZ1; Mon, 29 Apr 2013 22:11:51 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7245921F99DB; Mon, 29 Apr 2013 22:11:50 -0700 (PDT) X-AuditID: 12074422-b7f5b6d00000095d-d9-517f5295b925 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 3D.2A.02397.5925F715; Tue, 30 Apr 2013 01:11:49 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r3U5Bm4J002161; Tue, 30 Apr 2013 01:11:49 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r3U5Bjhd016446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Apr 2013 01:11:47 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r3U5Bikl001454; Tue, 30 Apr 2013 01:11:44 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-oauth-revocation.all@tools.ietf.org From: Tom Yu Date: Tue, 30 Apr 2013 01:11:44 -0400 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixCmqrDs1qD7Q4MNtWYs5Hd+ZLGb8mchs 8WHhQxYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK2P2i7fMBW9ZK2Y1LWNrYHzD0sXI ySEhYCJx4PkPNghbTOLCvfVANheHkMA+RonuvWuZIJyNjBJrpp1iBqkSEjjHJLFpQgBEootR YlL/FXaQhIhAtMTVr7/AbGEBC4nmc5OAujk42ASkJY4uLgMJswioSsydMgNsMy9QyfKtN1lB bB4BTon1/c8YIeKCEidnPgGrYRbQkrjx7yXTBEa+WUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3W LU5OzMtLLdI11cvNLNFLTSndxAgKNXYXpR2MPw8qHWIU4GBU4uHdsaQuUIg1say4MvcQoyQH k5Iob4R3faAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd5oR6Acb0piZVVqUT5MSpqDRUmc91rK TX8hgfTEktTs1NSC1CKYrAwHh5IE7/9AoEbBotT01Iq0zJwShDQTByfIcB6g4W9AaniLCxJz izPTIfKnGBWlxHkvgCQEQBIZpXlwvbBU8IpRHOgVYd67IFU8wDQC1/0KaDAT0OB5jdUgg0sS EVJSDYwFi48YrPC9JhR5c2vyo6Z9b7RMOiMf/jE4/mLprFN/bsb+tzrvwnDt6SrNjXI+yZXP XDfFryuZ0dxfnnaaw9TjeXejUvx+/taG+/KziuYyLM95/r6gREdyi5TIns0ro04VX7W+/3ji uq/u3E38G7g8csOs5x2NeTUzxdJU4PiZD/bz36/U2dyixFKckWioxVxUnAgAfzojTeACAAA= Subject: [secdir] secdir review of draft-ietf-oauth-revocation-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 05:11:57 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I find the security considerations section of this document to be mostly adequate. It should probably mention the importance of authenticating the endpoint (certificate validation etc.), especially if the token is a bearer token. Someone who is more familiar with the implications of cross-origin issues should look at Section 2.3 to determine whether additional security considerations need mentioning.