From Hannes.Tschofenig@gmx.net Sat May 1 04:02:40 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1F73A67AC for ; Sat, 1 May 2010 04:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiOSaVpAPGaJ for ; Sat, 1 May 2010 04:02:38 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7425E3A6834 for ; Sat, 1 May 2010 04:02:37 -0700 (PDT) Received: (qmail invoked by alias); 01 May 2010 11:02:21 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.2]) [88.115.222.204] by mail.gmx.net (mp063) with SMTP; 01 May 2010 13:02:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/leN9/ADHlYKdJlcUZ/eSVaf296qDK/kw6q1i94x ZMSH3ERiWtS2b5 Message-ID: <4BDC0A38.20507@gmx.net> Date: Sat, 01 May 2010 14:02:16 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Weis References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> In-Reply-To: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 Cc: nsis-chairs@tools.ietf.org, draft-ietf-nsis-rmd@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 11:02:40 -0000 Hey Brian, thanks for your detailed review. I have updated the security consideration section based on your comments. I have added text to describe security threats in more detail, discuss what the assumptions are (trust model), provide security requirements, and updated the part that talks about the specific solution mechanisms. I also added a sentence about the authorization aspect you mentioned. There is nothing special about RMD that would require additional description beyond what is covered in the QoS NSLP and the solutions we had worked on in the context of the Diameter QoS application. The authorizatoin aspect largely happens before RMD signaling is actually triggered. My proposed text can be found below (before Georgios adds it to the draft itself). Ciao Hannes --------------- 5. Security Considerations I. INTRODUCTION A design goal of the RMD-QOSM protocol is to be "lightweight" in terms of the number of exchanged signaling message and the amount of state established at involved signaling nodes (with and without reduced state operation). A side-effect of this design decision is to introduce second-class signaling nodes, namely QNE Interior nodes, that are restricted in their ability to perform QoS signaling actions. Only the QNE Ingress and the QNE Egress nodes are allowed to initiate certain signaling messages. Moreover, RMD focuses on an intra-domain deployment only. The above description has the following implications for security: 1) QNE Ingress and QNE Egress nodes require more security and fault protection than QNE Interior nodes because their uncontrolled behavior has larger implications for the overall stability of the network. 2) The focus on intra-domain QoS signaling simplifies trust management and reduces overall complexity. See Section 2 of RFC 4081 for a more detailed discussion about the complete set of communication models available for end-to-end QoS signaling protocols. It is important to highlight that RMD always uses the message exchange shown in Figure 24 even if there is no end-to-end signaling session. If the RMD-QOSM is triggered based on an E2E signaling exchange then the RESERVE message is created by a node outside the RMD domain and will subsequently travel further on (e.g., to the data receiver). Such an exchange is shown in Figure 3. As such, an evaluation of RMD's security always has to be seen as a combination of the two signaling sessions, (1) and (2) of Figure 24. QNE QNE QNE QNE Ingress Interior Interior Egress NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | | RESERVE (1) | | | +--------------------------------------------->| | RESERVE` (2) | | | +-------------->| | | | | RESERVE` | | | +-------------->| | | | | RESERVE` | | | +------------->| | | | RESPONSE` (2)| |<---------------------------------------------+ | | | RESPONSE (1) | |<---------------------------------------------+ Figure 24: RMD Message Exchange. Authorizing quality of service reservations is accomplished using the AAA framework and the functionality is inherited from the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], and not described again in this document. As a technical solution mechanism Diameter QoS application [I-D.ietf-dime-diameter-qos] may be used. II. SECURITY THREATS In the RMD-QOSM, the ingress node constructs both end-to- end and intra-domain signaling messages based on the end-to-end message initiated by the sender end node. The Interior nodes within the RMD network ignore the end-to-end signaling message, but process, modify, and forward the intra-domain signaling messages towards the egress node. In the meantime, resource reservation states are installed, modified or deleted at each interior node along the data path according to the content of each intra-domain signaling message. The edge nodes of an RMD network are critical components that require strong security protection. Therefore, they act as security gateways for incoming and outgoing signaling messages. Moreover, a certain degree of trust has to be placed into Interior nodes within the RMD-QOSM network, such that these nodes can perform signaling message processing and take the necessary actions. With the RMD-QOSM we assume that the ingress and the egress nodes are not controlled by an adversary and the communication between the ingress and the egress nodes is secured using standard GIST security mechanisms and experiences integrity, replay and confidentiality protection. Note that this only affects messages directly addressed by these two nodes and not any other message that needs to be processed by intermediaries. The SESSION ID object of the end-to-end communication is visible, via GIST, to the Interior nodes. In order to define the security threats that are associated with the RMD-QOSM we consider that an adversary that may be located inside the RMD domain and could drop, delay, duplicate, inject, or modify signaling packets. Depending on location of adversary, we speak about an on-path adversary or an off-path adversary, see also RFC 4081 [RFC4081]. II-A. On-path Adversary The on-path adversary is a node, which supports RMD-QOSM and is able to observe RMD-QOSM signaling message exchanges. 1) Dropping signaling messages An adversary could drop any signaling messages after receiving them. This will cause a failure of reservation request for new sessions or deletion of resource units (bandwidth) for on-going sessions due to states timeout. It may trigger the ingress node to retransmit the lost signaling messages. In this scenario the adversary drops selected signaling messages, for example intra-domain reserve messages. In the RMD-QOSM, the retransmission mechanism can be provided at the ingress node to make sure that signaling messages can reach the egress node. However, the retransmissions triggered by the adversary dropping messages may cause certain problems. Therefore, it is recommended to disable the use of retransmissions in the RMD-QOSM aware network. 2) Delaying Signaling Messages Any signaling message could be delayed by an adversary. For example, if RESERVE` messages are delayed over the duration of the refresh period then the resource units (bandwidth) reserved along the nodes for corresponding sessions will be removed. In this situation, the ingress node does not receive the RESPONSE within a certain period, and considers that the signaling message is failed, which may cause a retransmission of the ’failed’ message. The egress node may distinguish between the two messages, i.e., the delayed message and the retransmitted message, and it could take a proper response. However, interior nodes suffer from this retransmission and they may reserve twice the resource units (bandwidth) requested by the ingress node. 3) Replaying Signaling Messages An adversary may want to replay signaling messages. It first stores the received messages and decides when to replay these message and at what rate (packets/per seconds). When the RESERVE` message carried a RII object, the egress will reply with a RESPONSE` message towards the ingress node. The ingress node can then detect replays by comparing the value of RII in the RESPONSE` messages with the stored value. 4) Injecting Signaling Messages Similar to the replay-attack scenario, the adversary may store a part of the information carried by signaling messages, for example, the RSN object. When the adversary injects signaling messages, it puts the stored information together with its own generated parameters (Bandwidth, RII, etc.) into the injected messages and then sends them out. Interior nodes will process these messages by default, reserve the requested resource units (bandwidth) and pass them to downstream nodes. It may happen that the resource units (bandwidth) on the Interior nodes are exhausted if these injected messages consume much bandwidth. 5) Modifying Signaling Messages On-path adversaries are capable of modifying any part of the signaling message. For example, the adversary can modify the , and parameters of the RMD-QSPEC messages. The egress node will then use the SESSION ID and subsequently the BOUND SESSION ID objects to refer to that flow to be terminated or set to lower priority. It is also possible for the adversary to modify the and/or parameter, which could cause a modification of an amount of the requested resource units (bandwidth) changes. II-B. Off-path Adversary In this case the adversary is not located on-path and it does not participate in the exchange of RMD-QOSM signaling messages, and therefore is unable to eavesdrop signaling messages. Hence, the adversary does not know valid RIIs, RSNs, SESSION IDs. Hence, the adversary has to generate new parameters and constructs new signaling messages. Since Interior nodes operate in reduced state mode, injected signaling messages are treated as new once, which causes Interior nodes to allocate additional reservation state. III. SECURITY REQUIREMENTS The following security requirements are set as goals for the intra-domain communication, namely: * Nodes, which are never supposed to participate in the NSIS signaling exchange, must not interfere with QNE Interior nodes. Off-path nodes (off-path with regard to the path taken by a particular signaling message exchange) must not be able to interfere with other on-path signaling nodes. * The actions allowed by a QNE Interior node should be minimal (i.e., only those specified by the RMD-QOSM). For example, only the QNE Ingress and the QNE Egress nodes are allowed to initiate certain signaling messages. QNE Interior nodes are, for example, allowed to modify certain signaling message payloads. Note that the term `interfere` refers to all sorts of security threats, such as denial of service, spoofing, replay, signaling message injection, etc. III. SECURITY MECHANISMS An important security mechanism that was built into RMD-QOSM was the ability to tie the end-to-end RESERVE and the RESERVE` messages together using the BOUND SESSION ID and to allow the ingress node to match the RESERVE` with the RESPONSE` by using the RII. These mechanisms enable the edge nodes to detect unexpected signaling messages. We assume that the RESERVE/RESPONSE is sent with hop-by-hop channel security provided by GIST and protected between the QNE Ingress and the QNE Egress. GIST security mechanisms MUST be used to offer authentication, integrity, and replay protection. Furthermore, encryption MUST be used to prevent an adversary located along the path of the RESERVE message to learn information about the session that can later be used to inject a RESERVE` message. The following messages need to be mapped to each other to make sure that the occurrence of one message is not without the other one: a) the RESERVE and the RESERVE` relate to each other at the QNE Egress and b) the RESPONSE and the RESERVE relate to each other at the QNE Ingress and c) the RESERVE` and the RESPONSE` relate to each other. The RII is carried in the RESERVE` message and the RESPONSE` message that is generated by the QNE Egress node contains the same RII as the RESERVE`. The RII can be used by the QNE Ingress to match the RESERVE` with the RESPONSE`. The QNE Egress is able to determine whether the RESERVE` was created by the QNE Ingress node since the intra-domain session, which sent the RESERVE`, is bound to an end-to- end session via the BOUND_SESSION_ID value included in the intra- domain QoS-NSLP operational state maintained at the QNE Egress. The RESERVE and the RESERVE` message are tied together using the BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end QoS-NSLP operational states maintained at the QNE edges, see Section 4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a corresponding RESERVE. The SESSION_ID can fulfill this purpose quite well if the aim is to provide protection against off-path adversaries that do not see the SESSION_ID carried in the RESERVE and the RESERVE` messages. If, however, the path changes (due to re-routing or due to mobility) then an adversary could inject RESERVE` messages (with a previously seen SESSION_ID) and could potentially cause harm. An off-path adversary can, of course, create RESERVE` messages that cause intermediate nodes to create some state (and cause other actions) but the message would finally hit the QNE Egress node. The QNE Egress node would then be able to determine that there is something going wrong and generate an error message. The severe congestion handling can be triggered by intermediate nodes (unlike other messages). In many cases, however, intermediate nodes experiencing congestion use refresh messages modify the and parameters of the message. These messages are still initiated by the QNE Ingress node and carry the SESSION_ID. The QNE Egress node will use the SESSION_ID and subsequently the BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP operational state, to refer to a flow that might be terminated. The aspect of intermediate nodes initiating messages for severe congestion handling is for further study. QNE Ingress QNE Interior QNE Interior QNE Egress NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | | REFRESH RESERVE` | | +-------------->| REFRESH RESERVE` | | (+RII) +-------------->| REFRESH RESERVE` | | (+RII) +------------->| | | | (+RII) | | | | | | | | REFRESH | | | | RESPONSE`| |<---------------------------------------------+ | | | (+RII) | Figure 25: RMD REFRESH message exchange During the refresh procedure a RESERVE` creates a RESPONSE`, see Figure 25. The RII is carried in the RESERVE` message and the RESPONSE` message that is generated by the QNE Egress node contains the same RII as the RESERVE`. The RII can be used by the QNE Ingress to match the RESERVE` with the RESPONSE`. A further aspect is marking of data traffic. Data packets can be modified by an intermediary without any relationship to a signaling session (and a SESSION_ID). The problem appears if an off-path adversary injects spoofed data packets. The adversary thereby needs to spoof data packets that relate to the flow identifier of an existing end-to-end reservation that SHOULD be terminated. Therefore the question arises how an off-path adversary SHOULD create a data packet that matches an existing flow identifier (if a 5-tuple is used). Hence, this might not turn out to be simple for an adversary unless we assume the previously mentioned mobility/re-routing case where the path through the network changes and the set of nodes that are along a path changes over time. Brian Weis 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. > > This document describes an NSIS QoS Model for networks that use the > Resource Management in Diffserv (RMD) concept. It describes RMD-QOSM, > which are new payloads sent using the GISP signaling mechanism, where > the new payloads request or reserve resources. A number of data flows > are discussed, depending on whether nodes within a network boundary > participate in the protocol or not. > > The Security Considerations section covers the following topics: > - Byzantine adversaries (i.e., participants taken over by an > adversary) are a general problem, but this section intends to discuss > additional threats as a result of the new protocol. There is an > extensive discussion of on-path and off-path adversaries, which seems > to intend to be addressing Byzantine adversaries. > - RMD-QOSM is claimed to be lightweight, with different routers > allowed certain operations dependant on the role a router plays in the > system. E.g., only Ingress/Egress nodes are allowed to initiate > certain signaling messages. > - RMD-QOSM "relies on the security support that is provided by the > bounded end-to-end session, which is running between the boundaries of > the RMD domain", but doesn't mandate that security support. > > The existing text is helpful, but not sufficient. The following points > are suggestions to improve this section. > > 1. The statement at the beginning of Security Considerations discusses > adversaries taking over a router, but the new threats are not very > clear. Are the authors considering that security associations are > revealed, that reservation data routed to a particular router can be > changed or forged, or something else? > > 2. The trust model used by RMD-QOSM is hinted at in the discussion of > on-path and off-path adversaries, but a discussion of exactly what > devices are trusted and what they're trusted to do would be helpful. > For example, is every interior router in the network is trusted to > handle any particular RESERVE or RESERVE` message? If not, then how > are the paths setup so that only authorized routers will see a > particular message? On the other hand, if routing is used to route the > messages then it would seem that any router must be authorized to > handle messages happened to be routed to them -- but then it isn't > clear that there can be a difference between an "on-path" and > "off-path" adversary. > > 3. Another dimension of trust model is the fact that ingress/egress > routers seem to trust each other more than they trust interior nodes. > This seems evidenced by the fact that RESERVE messages (Figure 24) > don't seem to be intended to be modified by the interior routers. In > the case of probes, I would expect that this would be especially > important, but probes do not seem to be specifically discussed in this > section. > > 4. There don't seem to be any actual security requirements or > recommendations made on GIST messaging. As such, it isn't clear that > attackers that have not taken over a participant (i.e., a man in the > middle) are in any way foiled. I would expect to see more MUSTs and > SHOULDs in this section regarding message security. There are > statements in the I-D such as "In the situation a security association > exists" and "If we assume that the RESERVE/RESPONSE is sent with > hop-by-hop channel security". There should be some description of the > threats to the messaging by a non-participant, and stating what > available mechanisms MUST or SHOULD be used. > > 5. Since roles seem to be an important part of the security > considerations, it would be helpful to see discussion of the different > threats & requirements on the ingress/egress routers and the internal > routers in their different roles. > > 6. An important service of RMD-QOSM is admission control, but there > doesn't seem to be any discussion of how the ingress routers determine > whether or not reservation requests given to them are valid. I would > have thought that is of particular importance, but if it's considered > out of scope this section might mention that fact. > > Hope that helps, > Brian > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From vincent.roca@inrialpes.fr Mon May 3 13:16:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA973A695D; Mon, 3 May 2010 13:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwBbs05bpzjj; Mon, 3 May 2010 13:16:28 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 002DD3A6909; Mon, 3 May 2010 13:16:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,321,1270418400"; d="scan'208";a="50343518" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-pro-de-roca.local) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 03 May 2010 22:16:08 +0200 Message-ID: <4BDF2F06.2030406@inrialpes.fr> Date: Mon, 03 May 2010 22:16:06 +0200 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-keyprov-pskc.all@tools.ietf.org Subject: [secdir] SecDir review of draft-ietf-keyprov-pskc-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 20:16:30 -0000 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. 1- section 13: about the use of the reserved keywords... On many places I have the feeling that the authors are not sufficiently directive. Two examples (others will follow): * introduction: must => MUST in sentence: "This means that special care must be taken to ensure the confidentiality..." * 13.1: before the last paragraph of the first solution, add: "Additionally, it is strongly RECOMMENDED that practical implementations use PBESalt and PBEIterationCount when PBE encryption is used." 2- section 13, about the use of the term "payload" in titles: After reading the introduction of section 13, I understand that "payload" refers to "the information contained within [a PSKC container]". However I have the feeling that the three desired security services are for the whole PSKC container, not only "the information contained within". The titles are therefore a little bit misleading IMHO. 3- section 13.1: rather than "one of the password-based encryption methods provided above", I suggest the authors add an explicit reference to section 6.2. 4- section 13.1: it is said: "Different PBESalt value per key container should be used for best protection." It's rather ambiguous. It's not clear to me whether it is recommended to use a different PBESalt for each PSKC container, or whether it is recommended to use a different PBESalt when a given PSKC container carries several keys, one PBESalt per key. Also: "should" => "SHOULD" 5- section 13.1: why isn't the IPsec/ESP not considered also as a third solution to provide the confidentiality, integrity and sender authentication services? Why do the authors only focus on PCKS integrated or TLS solutions? It's not clear. 6- section 13.1, last but one paragraph: The authors say that TLS offers extra security measures, especially when the digital signature does not encompass the entire payload. I agree, but section 13.1 is dedicated to confidentiality, not to integrity/authenticity verifications. Referring to digital signatures is meaningless in this section. 7- section 13.1, last paragraph: Instead of: "Validating the secure channel end-points" I'd rather say: "Authenticating". 8- sections 13.1, 13.2 and 13.3: It is mentioned on several places that TLS can be useful in situations where "the signature of the payload does not encompass the entire payload". Shouldn't the authors RECOMMEND that the digital signature encompass the whole payload instead? It would clarify... This is all the more true if TLS is not used, in which case this is strongly RECOMMENDED. 9- section 13.3: it is said: "A weaker payload authenticity guarantee may be provided by the transport layer if it is configured to digest each message it transports." Why is this feature necessarily weaker? The source can be authenticated with the same level of security as if it was done by the recipient end. Typos: * section 13.1 (also section 3): Rather than saying "the portable key container", I suggest the authors either write everything in extenso, or use the PSKC acronym. * section 6.3, first sentence: a comma is missing between "element information", making the sentence difficult to understand. Regards, Vincent From jhutz@cmu.edu Mon May 3 14:26:22 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932793A6A9A; Mon, 3 May 2010 14:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.714 X-Spam-Level: X-Spam-Status: No, score=-4.714 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+GiOkNDAMeK; Mon, 3 May 2010 14:26:21 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 7182C3A68BB; Mon, 3 May 2010 14:26:21 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o43LQ5c6015591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 17:26:05 -0400 (EDT) Date: Mon, 03 May 2010 17:26:05 -0400 From: Jeffrey Hutzelman To: ietf@ietf.org, secdir@ietf.org, draft-lawrence-sipforum-user-agent-config.all@tools.ietf.org Message-ID: <7DABD47951EF7DFC7760C11C@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Subject: [secdir] secdir review of draft-lawrence-sipforum-user-agent-config-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 21:26:22 -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 describes a process by which a SIP User Agent can obtain configuration from a Configuration Service (CS) with a minimum of user interaction. This is particularly important since SIP UA's may be included in devices such as telephone adapters which are installed by end users and have little or no provision for user interface. The process described is relatively straightforward: - use LDDP-MED to get layer 2 up - use DHCP to get layer 3 up, and discover a local domain name - use U-NAPTR to turn the "configuration service name" (either the local domain name or a manually-entered name) into a set of one or more base configuration URL's - add some query parameters identifying the client, and use HTTPS GET Section 2.4.1 discusses authentication. The client is required to use the TLS server_name extension; however, the server name it is required to request is the name taken from the host part of the URL(s) obtained from U-NAPTR, rather than the Configuration Service Name (i.e. the local domain name or a manually-configured name). The latter should be used, so that the DNS-based indirection facilities are not required to be secure for the system to work. While DHCP is almost universally not secured, eliminating the need for pre-secured DNS still provides a substantial improvement. First, it is relatively easy for a deployment to require a user to enter a configuration service name rather than relying on one obtained from DNS. In fact, it may even be necessary to do so; for example, a telephone service provider offering SIP phone service to users via their existing home network cannot rely on being able to provide a particular domain name in the DHCP responses provided by an ISP or by the user's consumer-grade router/NAT box. Second, the resolution of the CS name to a base URL may require DNS queries to the internet at large, outside the user's network. Again, consider the case of a telephone service provider offering service via the user's existing network. This section says the UA SHOULD validate server certificates if possible, and otherwise MAY use SSH-style leap-of-faith. This seems reasonable for this application, where the use is provisioning a new device which, by definition, usually cannot have previously-provisioned trust anchors. Clients are REQUIRED to send a certificate if they have one, but are not required to have one. A CS SHOULD validate the client's certificate, and otherwise MAY do leap-of-faith caching, provided that HTTP authentication succeeds on this connection. However, it is unclear what, if anything, the client certificate identity is used for. If this identity is not used, then use of client certificates is pointless. Further, since HTTP authentication is not cryptographically bound to the TLS layer, successful HTTP auth does not demonstrate anything about the validity of the client certificate. From tlyu@mit.edu Mon May 3 22:29:06 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E0D28C381; Mon, 3 May 2010 22:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.741 X-Spam-Level: X-Spam-Status: No, score=0.741 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwxOwRIxT4FR; Mon, 3 May 2010 22:29:05 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by core3.amsl.com (Postfix) with ESMTP id 9AC2F3A68A3; Mon, 3 May 2010 22:23:49 -0700 (PDT) X-AuditID: 1209190f-b7b20ae000003f85-1e-4bdfaf57bcc4 Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id F7.1D.16261.75FAFDB4; Tue, 4 May 2010 01:23:35 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o445NXCU027471; Tue, 4 May 2010 01:23:35 -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.6/8.12.4) with ESMTP id o445NWLJ010943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 May 2010 01:23:33 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o445NWhi014878; Tue, 4 May 2010 01:23:32 -0400 (EDT) To: secdir@ietf.org, iesg@ietf.org, ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-ikev2bis.all@tools.ietf.org From: Tom Yu Date: Tue, 04 May 2010 01:23:32 -0400 Message-ID: Lines: 52 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAARPvoAQ= Subject: [secdir] review of draft-ietf-ipsecme-ikev2bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 05:29:06 -0000 draft-ietf-ipsecme-ikev2bis-10 document intends to replace RFC 4306, the previous specification of IKEv2. My comments focus on the Security Considerations section, which mostly the same as in RFC 4306. None of these comments represents a major issue. Compared to RFC 4306, the Security Considerations section of this document contains additional comments about implementation robustness against attacks (including exhaustion of computational resources) by unauthenticated peers. The following sentence from RFC 4306, referring to Diffie-Hellman exponents, is not present in this document: In particular, these exponents MUST NOT be derived from long-lived secrets like the seed to a pseudo-random generator that is not erased after use. I understand that this sentence was removed because it is impractical for many implementations to comply. For reasonable interpretations of the randomness requirements which are listed a few paragraphs later, I believe it is possible to securely implement this specification without satisfying the RFC 4306 condition on erasing certain pseudo-random number generator seeds after use. The paragraph on the randomness requirements would therefore subsume the above RFC 4306 condition that was deleted. Do the authors agree? The lengthy paragraph warning about non-key-generating EAP methods is mostly unchanged from RFC 4306. I do wonder if channel bindings would help with non-key-generating EAP methods tunneled in protected channels, but am not sufficiently familiar with EAP to know whether this is feasible. (non-key-generating EAP methods might not have any way to perform the additional necessary authentication to achieve channel binding) The SHOULD in RFC 4306 in the sentence beginning "Implementers SHOULD describe the vulnerabilities of non-key-generating EAP methods..." was demoted to a non-capitalized form. Is this intentional? If so, what is the rationale? This document adds a paragraph about "admission control", a term for which I am unable to find a contextually meaningful definition. I agree with the importance of choosing a more carefully evaluated set of trust anchors for IKE authentication than for identification of public web servers, but I am uncertain how that statement relates to (network?) admission control in that paragraph. The added section (5.1) on traffic selector authorization seems reasonable to me. Editorial: "elliptical curve" -> "elliptic curve" From weiler+secdir@watson.org Tue May 4 02:10:51 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160F93A69C1 for ; Tue, 4 May 2010 02:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id josqqLcPt+aV for ; Tue, 4 May 2010 02:10:50 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id C7C773A69EE for ; Tue, 4 May 2010 02:10:49 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o449AZEa086921 for ; Tue, 4 May 2010 05:10:35 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o449AYkc086918 for ; Tue, 4 May 2010 05:10:34 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 4 May 2010 05:10:34 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 04 May 2010 05:10:35 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 04 May 2010 09:10:51 -0000 The last assignment message was last Tuesday. I wanted to wait 'til Friday for this one, but I'm traveling again on Friday and enough has changed that it's worth sending this now. Four new assignments (to Glen Zorn, Donald Eastlake, Richard Barnes, and Pat Cain) are of docs already scheduled for the May 20th telechat. Tobias Gondrom is next in the rotation. Documents on the telechat agenda typically have a last call end date before the date shown below; reviews by the end of last call are typically more appreciated by the doc editors. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-05-06 Dave Cridland T 2010-05-04 draft-ietf-isms-dtls-tm-10 Tobias Gondrom TR2010-05-04 draft-mattsson-mikey-ticket-03 Chris Newman T 2010-05-04 draft-ietf-ipsecme-aes-ctr-ikev2-07 Magnus Nystrom TR2010-05-04 draft-altman-tls-channel-bindings-10 Eric Rescorla T 2010-05-04 draft-ietf-keyprov-dskpp-10 Tina TSOU T 2010-05-04 draft-ietf-mext-flow-binding-06 For telechat 2010-05-20 Richard Barnes T 2010-05-18 draft-ietf-csi-send-cert-03 Pat Cain T 2010-05-18 draft-ietf-csi-send-name-type-registry-03 Donald Eastlake T 2010-05-18 draft-ietf-netlmm-mip-interactions-06 David McGrew T 2010-05-18 draft-turner-encryptedkeypackagecontenttype-algs-01 Nico Williams T 2010-05-18 draft-ietf-opsec-routing-protocols-crypto-issues-04 Glen Zorn T 2010-05-18 draft-ietf-6lowpan-routing-requirements-06 For telechat 2010-06-03 Tom Yu TR2010-06-01 draft-krishnan-v6ops-teredo-update-06 Last calls and special requests: Derek Atkins 2010-05-11 draft-ietf-avt-rtp-gsm-hr-03 Rob Austein 2010-05-14 draft-ietf-bmwg-protection-term-08 Dave Cridland 2010-05-14 draft-ietf-marf-base-04 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-05 Alan DeKok 2010-05-12 draft-ietf-netconf-monitoring-12 Shawn Emery 2010-05-17 draft-ietf-mboned-ipv4-uni-based-mcast-06 Stephen Farrell 2010-05-31 draft-kucherawy-authres-header-b-01 Steve Hanna None draft-ietf-tsvwg-ecn-tunnel-08 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows None draft-ietf-tsvwg-dtls-for-sctp-05 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Sam Weiler 2010-05-19 draft-hoffman-tls-additional-random-ext-01 Brian Weis 2010-05-19 draft-sheffer-emu-eap-eke-06 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Tom Yu 2010-05-10 draft-ietf-avt-rtcp-guidelines-03 Kurt Zeilenga 2010-05-11 draft-ietf-radext-tcp-transport-06 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-06 Larry Zhu 2010-05-24 draft-santoni-media-type-tsd-00 From Hannes.Tschofenig@gmx.net Tue May 4 05:46:01 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0463A6C09 for ; Tue, 4 May 2010 05:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+-VeKtrp-bQ for ; Tue, 4 May 2010 05:45:59 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5710628C0E9 for ; Tue, 4 May 2010 05:45:14 -0700 (PDT) Received: (qmail invoked by alias); 04 May 2010 12:44:59 -0000 Received: from m500f36d0.tmodns.net (EHLO [10.223.99.52]) [208.54.15.80] by mail.gmx.net (mp018) with SMTP; 04 May 2010 14:44:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19QxtsVZllQfnbywWUZkgJbiefwrfgK26QaWdEWhJ 0iHeS6DuNeK02c Message-ID: <4BE016C1.2030002@gmx.net> Date: Tue, 04 May 2010 05:44:49 -0700 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hannes Tschofenig References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> <4BDC0A38.20507@gmx.net> In-Reply-To: <4BDC0A38.20507@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 Cc: 'NSIS' , secdir@ietf.org, nsis-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-nsis-rmd@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 12:46:01 -0000 Georgios told me that he did not see my response to your mail. Let me re-send it again. Ciao Hannes Hannes Tschofenig wrote: > Hey Brian, > > thanks for your detailed review. > > I have updated the security consideration section based on your > comments. I have added text to describe security threats in more > detail, discuss what the assumptions are (trust model), provide > security requirements, and updated the part that talks about the > specific solution mechanisms. > > I also added a sentence about the authorization aspect you mentioned. > There is nothing special about RMD that would require additional > description beyond what is covered in the QoS NSLP and the solutions > we had worked on in the context of the Diameter QoS application. The > authorizatoin aspect largely happens before RMD signaling is actually > triggered. > > My proposed text can be found below (before Georgios adds it to the > draft itself). > > Ciao > Hannes > > --------------- > > > 5. Security Considerations > > I. INTRODUCTION > > A design goal of the RMD-QOSM protocol is to be "lightweight" in terms > of the number of exchanged signaling message and the amount of state > established at involved signaling nodes (with and without reduced > state operation). A side-effect of this design decision is to introduce > second-class signaling nodes, namely QNE Interior nodes, that are > restricted > in their ability to perform QoS signaling actions. Only the QNE > Ingress and > the QNE Egress nodes are allowed to initiate certain signaling messages. > Moreover, RMD focuses on an intra-domain deployment only. > > The above description has the following implications for security: > > 1) QNE Ingress and QNE Egress nodes require more security and fault > protection > than QNE Interior nodes because their uncontrolled behavior has larger > implications for the overall stability of the network. > > 2) The focus on intra-domain QoS signaling simplifies trust management > and > reduces overall complexity. See Section 2 of RFC 4081 for a more detailed > discussion about the complete set of communication models available for > end-to-end QoS signaling protocols. > > It is important to highlight that RMD always uses the message exchange > shown in Figure 24 > even if there is no end-to-end signaling session. If the RMD-QOSM is > triggered based on an E2E signaling exchange then the RESERVE message > is created by a node outside the RMD domain and will subsequently > travel further on (e.g., to the data receiver). Such an exchange is > shown in Figure 3. As such, an evaluation of RMD's security > always has to be seen as a combination of the two signaling sessions, (1) > and (2) of Figure 24. > > QNE QNE QNE QNE > Ingress Interior Interior Egress > NTLP stateful NTLP stateless NTLP stateless NTLP stateful > | | | | > | RESERVE (1) | | | > +--------------------------------------------->| > | RESERVE` (2) | | | > +-------------->| | | > | | RESERVE` | | > | +-------------->| | > | | | RESERVE` | > | | +------------->| > | | | RESPONSE` (2)| > |<---------------------------------------------+ > | | | RESPONSE (1) | > |<---------------------------------------------+ > > Figure 24: RMD Message Exchange. > > Authorizing quality of service reservations is accomplished > using the AAA framework and the functionality is inherited from > the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], > and not described again in this document. As a technical > solution mechanism Diameter QoS application > [I-D.ietf-dime-diameter-qos] may be used. > > > II. SECURITY THREATS > > In the RMD-QOSM, the ingress node constructs both end-to- > end and intra-domain signaling messages based on the > end-to-end message initiated by the sender end node. The > Interior nodes within the RMD network ignore the end-to-end > signaling message, but process, modify, and forward the intra-domain > signaling messages towards the egress node. In the > meantime, resource reservation states are installed, modified > or deleted at each interior node along the data path according > to the content of each intra-domain signaling message. The > edge nodes of an RMD network are critical components > that require strong security protection. Therefore, they act > as security gateways for incoming and outgoing signaling > messages. Moreover, a certain degree of trust has to be placed > into Interior nodes within the RMD-QOSM network, such that > these nodes can perform signaling message processing and > take the necessary actions. > > With the RMD-QOSM we assume that the > ingress and the egress nodes are not controlled by an adversary > and the communication between the ingress and the egress > nodes is secured using standard GIST security mechanisms > and experiences integrity, replay and confidentiality protection. > Note that this only affects messages directly addressed by > these two nodes and not any other message that needs to > be processed by intermediaries. The SESSION ID object > of the end-to-end communication is visible, via GIST, to the > Interior nodes. > In order to define the security threats that are associated > with the RMD-QOSM we consider that an adversary that may be located > inside the RMD domain and could > drop, delay, duplicate, inject, or modify signaling packets. > Depending on location of adversary, we speak about an on-path > adversary or an off-path adversary, see also RFC 4081 [RFC4081]. > > > II-A. On-path Adversary > > The on-path adversary is a node, which supports RMD-QOSM > and is able to observe RMD-QOSM signaling message > exchanges. > > 1) Dropping signaling messages > > An adversary could drop any signaling messages after > receiving them. This will cause a failure of reservation > request for new sessions or deletion of resource units > (bandwidth) for on-going sessions due to states timeout. > It may trigger the ingress node to retransmit the > lost signaling messages. In this scenario the adversary > drops selected signaling messages, for example intra-domain reserve > messages. In the RMD-QOSM, the retransmission > mechanism can be provided at the ingress node > to make sure that signaling messages can reach the > egress node. However, the retransmissions triggered by > the adversary dropping messages may cause certain > problems. Therefore, it is recommended to disable the use > of retransmissions in the RMD-QOSM aware network. > > 2) Delaying Signaling Messages > > Any signaling message could be delayed by an adversary. > For example, if RESERVE` messages > are delayed over the duration of the refresh period then the resource > units > (bandwidth) reserved along the nodes for corresponding > sessions will be removed. In this situation, the ingress > node does not receive the RESPONSE within a certain > period, and considers that the signaling message is > failed, which may cause a retransmission of the ’failed’ > message. The egress node may distinguish between the > two messages, i.e., the delayed message and the retransmitted > message, and it could take a proper response. > However, interior nodes suffer from this retransmission > and they may reserve twice the resource units (bandwidth) > requested by the ingress node. > > 3) Replaying Signaling Messages > > An adversary may want to replay signaling messages. > It first stores the > received messages and decides when to replay these > message and at what rate (packets/per seconds). > When the RESERVE` message > carried a RII object, the egress will reply with a > RESPONSE` message towards the ingress node. The ingress > node can then detect replays by comparing the value of > RII in the RESPONSE` messages with the stored value. > > 4) Injecting Signaling Messages > > Similar to the replay-attack scenario, the adversary may > store a part of the information carried by signaling > messages, for example, the RSN object. When the > adversary injects signaling messages, it puts the stored > information together with its own generated parameters > (Bandwidth, RII, etc.) into the injected messages and > then sends them out. Interior nodes will process these > messages by default, reserve the requested resource units > (bandwidth) and pass them to downstream nodes. It > may happen that the resource units (bandwidth) on the > Interior nodes are exhausted if these injected messages > consume much bandwidth. > > 5) Modifying Signaling Messages > > On-path adversaries are capable of modifying any part > of the signaling message. For example, the adversary > can modify the , and parameters > of the RMD-QSPEC messages. The egress node > will then use the SESSION ID and subsequently the > BOUND SESSION ID objects to refer to that flow > to be terminated or set to lower priority. It is also > possible for the adversary to modify the > and/or parameter, which could cause > a modification of an amount of the requested resource > units (bandwidth) changes. > > II-B. Off-path Adversary > > In this case the adversary is not located on-path and it > does not participate in the exchange of RMD-QOSM signaling > messages, and therefore is unable to eavesdrop signaling > messages. Hence, the adversary does not know valid RIIs, > RSNs, SESSION IDs. Hence, the adversary has to generate > new parameters and constructs new signaling messages. Since > Interior nodes operate in reduced state mode, > injected signaling messages are treated as new once, which > causes Interior nodes to allocate additional reservation state. > > > III. SECURITY REQUIREMENTS > > The following security requirements are set as goals for the > intra-domain communication, namely: > > * Nodes, which are never supposed to participate in the NSIS signaling > exchange, must not interfere with QNE Interior nodes. Off-path > nodes (off-path with regard to the path taken by a particular > signaling message exchange) must not be able to interfere with > other on-path signaling nodes. > > * The actions allowed by a QNE Interior node should be minimal (i.e., > only those specified by the RMD-QOSM). For example, only the QNE > Ingress and the QNE Egress nodes are allowed to initiate certain > signaling messages. QNE Interior nodes are, for example, allowed to > modify certain signaling message payloads. > > Note that the term `interfere` refers to all sorts of security > threats, such as denial of service, spoofing, replay, signaling > message injection, etc. > > III. SECURITY MECHANISMS > > An important security mechanism that was > built into RMD-QOSM was the ability to tie the end-to-end > RESERVE and the RESERVE` messages > together using the BOUND SESSION ID and to allow the > ingress node to match the RESERVE` > with the RESPONSE` by using the > RII. These mechanisms enable the edge nodes to detect unexpected > signaling messages. > > We assume that the RESERVE/RESPONSE is sent with hop-by-hop > channel security provided by GIST and protected between the QNE > Ingress and the QNE Egress. GIST security mechanisms MUST be used > to offer authentication, > integrity, and replay protection. Furthermore, encryption MUST be used > to > prevent an adversary located along the path of the RESERVE > message to learn information about the session that can later be used > to inject a RESERVE` message. > > The following messages need to be mapped to > each other to make sure that the occurrence of one message is not > without the other one: > > a) the RESERVE and the RESERVE` relate to each other at the QNE > Egress and > > b) the RESPONSE and the RESERVE relate to each other at the QNE > Ingress and > > c) the RESERVE` and the RESPONSE` relate to each other. The RII is > carried in the RESERVE` message and the RESPONSE` message that is > generated by the QNE Egress node contains the same RII as the > RESERVE`. The RII can be used by the QNE Ingress to match the > RESERVE` with the RESPONSE`. The QNE Egress is able to determine > whether the RESERVE` was created by the QNE Ingress node since the > intra-domain session, which sent the RESERVE`, is bound to an end-to- > end session via the BOUND_SESSION_ID value included in the intra- > domain QoS-NSLP operational state maintained at the QNE Egress. > > The RESERVE and the RESERVE` message are tied together using the > BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end > QoS-NSLP operational states maintained at the QNE edges, see Section > 4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a > corresponding RESERVE. The SESSION_ID can fulfill this purpose quite > well if the aim is to provide protection against off-path adversaries > that do not see the SESSION_ID carried in the RESERVE and the > RESERVE` messages. > > If, however, the path changes (due to re-routing or due to mobility) > then an adversary could inject RESERVE` messages (with a previously > seen SESSION_ID) and could potentially cause harm. > > An off-path adversary can, of course, create RESERVE` messages that > cause intermediate nodes to create some state (and cause other > actions) but the message would finally hit the QNE Egress node. The > QNE Egress node would then be able to determine that there is > something going wrong and generate an error message. > > The severe congestion handling can be triggered by intermediate nodes > (unlike other messages). In many cases, however, intermediate nodes > experiencing congestion use refresh messages modify the and > parameters of the message. These messages are still > initiated by the QNE Ingress node and carry the SESSION_ID. The QNE > Egress node will use the SESSION_ID and subsequently the > BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP operational > state, to refer to a flow that might be terminated. The > aspect of intermediate nodes initiating messages for severe > congestion handling is for further study. > > QNE Ingress QNE Interior QNE Interior QNE Egress > NTLP stateful NTLP stateless NTLP stateless NTLP stateful > | | | | > | REFRESH RESERVE` | | > +-------------->| REFRESH RESERVE` | > | (+RII) +-------------->| REFRESH RESERVE` > | | (+RII) +------------->| > | | | (+RII) | > | | | | > | | | REFRESH | > | | | RESPONSE`| > |<---------------------------------------------+ > | | | (+RII) | > > Figure 25: RMD REFRESH message exchange > > During the refresh procedure a RESERVE` creates a RESPONSE`, see > Figure 25. The RII is carried in the RESERVE` message and the > RESPONSE` message that is generated by the QNE Egress node contains > the same RII as the RESERVE`. > > The RII can be used by the QNE Ingress to match the RESERVE` with the > RESPONSE`. > > A further aspect is marking of data traffic. Data packets can be > modified by an intermediary without any relationship to a signaling > session (and a SESSION_ID). The problem appears if an off-path > adversary injects spoofed data packets. > > > The adversary thereby needs to spoof data packets that relate to the > flow identifier of an existing end-to-end reservation that SHOULD be > terminated. Therefore the question arises how an off-path adversary > SHOULD create a data packet that matches an existing flow identifier > (if a 5-tuple is used). Hence, this might not turn out to be simple > for an adversary unless we assume the previously mentioned > mobility/re-routing case where the path through the network changes > and the set of nodes that are along a path changes over time. > > > > > Brian Weis 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. >> >> This document describes an NSIS QoS Model for networks that use the >> Resource Management in Diffserv (RMD) concept. It describes RMD-QOSM, >> which are new payloads sent using the GISP signaling mechanism, where >> the new payloads request or reserve resources. A number of data flows >> are discussed, depending on whether nodes within a network boundary >> participate in the protocol or not. >> >> The Security Considerations section covers the following topics: >> - Byzantine adversaries (i.e., participants taken over by an >> adversary) are a general problem, but this section intends to discuss >> additional threats as a result of the new protocol. There is an >> extensive discussion of on-path and off-path adversaries, which seems >> to intend to be addressing Byzantine adversaries. >> - RMD-QOSM is claimed to be lightweight, with different routers >> allowed certain operations dependant on the role a router plays in >> the system. E.g., only Ingress/Egress nodes are allowed to initiate >> certain signaling messages. >> - RMD-QOSM "relies on the security support that is provided by the >> bounded end-to-end session, which is running between the boundaries >> of the RMD domain", but doesn't mandate that security support. >> >> The existing text is helpful, but not sufficient. The following >> points are suggestions to improve this section. >> >> 1. The statement at the beginning of Security Considerations >> discusses adversaries taking over a router, but the new threats are >> not very clear. Are the authors considering that security >> associations are revealed, that reservation data routed to a >> particular router can be changed or forged, or something else? >> >> 2. The trust model used by RMD-QOSM is hinted at in the discussion of >> on-path and off-path adversaries, but a discussion of exactly what >> devices are trusted and what they're trusted to do would be helpful. >> For example, is every interior router in the network is trusted to >> handle any particular RESERVE or RESERVE` message? If not, then how >> are the paths setup so that only authorized routers will see a >> particular message? On the other hand, if routing is used to route >> the messages then it would seem that any router must be authorized to >> handle messages happened to be routed to them -- but then it isn't >> clear that there can be a difference between an "on-path" and >> "off-path" adversary. >> >> 3. Another dimension of trust model is the fact that ingress/egress >> routers seem to trust each other more than they trust interior nodes. >> This seems evidenced by the fact that RESERVE messages (Figure 24) >> don't seem to be intended to be modified by the interior routers. In >> the case of probes, I would expect that this would be especially >> important, but probes do not seem to be specifically discussed in >> this section. >> >> 4. There don't seem to be any actual security requirements or >> recommendations made on GIST messaging. As such, it isn't clear that >> attackers that have not taken over a participant (i.e., a man in the >> middle) are in any way foiled. I would expect to see more MUSTs and >> SHOULDs in this section regarding message security. There are >> statements in the I-D such as "In the situation a security >> association exists" and "If we assume that the RESERVE/RESPONSE is >> sent with hop-by-hop channel security". There should be some >> description of the threats to the messaging by a non-participant, and >> stating what available mechanisms MUST or SHOULD be used. >> >> 5. Since roles seem to be an important part of the security >> considerations, it would be helpful to see discussion of the >> different threats & requirements on the ingress/egress routers and >> the internal routers in their different roles. >> >> 6. An important service of RMD-QOSM is admission control, but there >> doesn't seem to be any discussion of how the ingress routers >> determine whether or not reservation requests given to them are >> valid. I would have thought that is of particular importance, but if >> it's considered out of scope this section might mention that fact. > >> >> Hope that helps, >> Brian >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir > > From matthew.bocci@alcatel-lucent.com Tue May 4 03:45:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA0128C0CE; Tue, 4 May 2010 03:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.906 X-Spam-Level: X-Spam-Status: No, score=-0.906 tagged_above=-999 required=5 tests=[AWL=-1.558, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lrqcXjI9d7C; Tue, 4 May 2010 03:45:54 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 19F0D3A6AF1; Tue, 4 May 2010 03:45:53 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o44AhHxo017035 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 May 2010 12:45:34 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.36]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 4 May 2010 12:44:46 +0200 From: "Bocci, Matthew (Matthew)" To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= , "draft-ietf-mpls-tp-framework@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Date: Tue, 4 May 2010 12:44:45 +0200 Thread-Topic: Secdir review of draft-ietf-mpls-tp-framework-11 Thread-Index: AcrnTXbwV0A+NXUGR36Mh5wme1noWgEHhhLw Message-ID: <030F37126795E34DB4796609C4FEAA4A127EA83AD1@FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com> References: In-Reply-To: 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_030F37126795E34DB4796609C4FEAA4A127EA83AD1FRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Tue, 04 May 2010 11:12:12 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-mpls-tp-framework-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 10:45:56 -0000 --_000_030F37126795E34DB4796609C4FEAA4A127EA83AD1FRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Magnus, Many thanks for your review. Please see below for some responses. Best regards, Matthew, Stewart and Dan ----- Original Message ----- From: "Magnus Nystr=F6m" > To: >; >; > Sent: Thursday, April 29, 2010 4:38 AM Subject: Secdir review of draft-ietf-mpls-tp-framework-11 >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 describes the architectural framework for applying MPLS > to transport networks. It is joint work with the ITU-T. > > The document does not contain any normative statements in the RFC 2119 > sense; presumably this is because the framework nature of the document > and/or the coupling to ITU-T, but it is a little concerning as there > are a number of "must", "should" and "may" statements in the document > that do look normative to me (e.g. "In cases where a MAC address is > needed, the sending node must set the destination MAC address to an > address that ensures delivery to the adjacent node."). The draft is informational, and therefore should not really include stateme= nts that look like normative instructions. However, the document has had extens= ive review in the ITU and they need some guidance as to some of the normative characte= ristics of MPLS-TP. Therefore there are some cases where we have quoted the relevan= t requirements documents and thereofre 'must' appears. In other cases we propose to change= 'must' to a statement such as 'needs to'. > > The security considerations section is very brief and consists mainly > of references to other, related documents' security considerations sectio= ns. > I > think it could have been beneficial if it had covered security aspects > stemming from the architectural framework and not only force the > reader to turn to the component documents. For example, since G-ACh > traffic is indistinguishable at the server layer from data traffic, is > it possible to craft data traffic messages that confuse a server to belie= ve it is G-ACh? These sorts of security considerations are covered by the data plane securi= ty discussion referenced from RFC5586->RFC5085 (VCCV). Since this is rather an indirect reference, we propose to add the following= text, which is based on that in RFC5085: " MPLS-TP nodes that implement the G-ACh create a Control Channel (CC) asso= ciated with a pseudowire, LSP or section. This control channel can be signaled= or statically configured. Over this control channel, control channel messa= ges related to network maintenance functions such as OAM, signaling or network manag= ement are sent. Therefore, three different areas are of concern from a security standpoi= nt. The first area of concern relates to control plane parameter and status message attacks, that is, attacks that concern the signaling of G-ACh capabilities. MPLS-TP Control Plane security is discussed in [I-D.ietf-mpls-gmpls-security-framework]. A second area of concern centers on data-plane attacks, that is, attacks on the G-ACh itself. MPLS-TP nodes that implement the G-ACh mechanisms are subject to additional data-plane denial-of- service attacks as follows: An intruder could intercept or inject G-ACh packets effectively disrupting the protocols carried over the G-ACh. An intruder could deliberately flood a peer MPLS-TP node with G-ACh messages to deny services to others. A misconfigured or misbehaving device could inadvertently flood a peer MPLS-TP node with G-ACh messages which could result in denial of services. In particular, if a node has either implicitly or explicitly indicated that it cannot support one or all of the types of G-ACh protocol, but is sent those messages in sufficient qua= ntity, it could result in a denial of service. To protect against these potential (deliberate or unintentional) attacks, multiple mitigation techniques can be employed: G-ACh message throttling mechanisms can be used, especially in distributed implementations which have a centralized control-plane processor with various line cards attached by some control-plane data path. In these architectures, G-ACh messages may be processed on the central processor after being forwarded there by the receiving line card. In this case, the path between the line card and the control processor may become saturated if appropriate G-ACh traffic throttling is not employed, which could lead to a complete denial of service to users of the particular line card. Such filtering is also useful for preventing the processing of unwanted G-ACh messages, such as those which are sent on unwanted (and perhaps unadvertised) control channel types. A third and last area of concern relates to the processing of the actual contents of G-ACh messages. It is necessary that the definition of the protocols using these messages carried over a G-ACh include appropriate security considerations." > Or, does the bandwidth sharing between control traffic and user data > traffic have any security implications? We have a warning in section 3.6 that sufficient bandwidth needs to be provisioned to cope with the expected G-ACh traffic on an LSP or PW. Howeve= r, this could of course be abused. For example, a malicious or faulty node could inject suff= icient traffic into A G-Ach to cause a DoS on the control processor of a receiving node. T= his is covered in the data plane portion of the security considerations text that = we propose to insert (see above). > Also, the NNI traffic may > involve signaling over the same channel as user data traverse which > may cause similar concerns (I am not an expert on MPLS or TP so these > threats may well not be realistic, however they serve only as > examples). > I think that the specific issue of isolation between user and control chann= el traffic is addressed by the proposed text above and by existing RFCs dealing with NNI-like applicat= ions of MPLS (e.g. RFC5659). I think we need to make it clear that when a particular architecture or pro= tocol belonging to MPLS is profiled for transport, the profile inherits the security considerations applicable to MPLS today. = I propose that we add a statement describing this to the start of the security considerations section: "When an MPLS function is included in the MPLS transport profile, the secur= ity considerations pertinent to that function apply to MPLS-TP." > (A minor editorial suggestion: Perhaps better if the list of acronyms > in Section 1.3 would be in alphabetical order?) Thanks. We will reorder the acronyms. > > -- Magnus > --_000_030F37126795E34DB4796609C4FEAA4A127EA83AD1FRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Magnus,
 
Many thanks for your review. Please see below fo= r some=20 responses.
 
Best regards,
 
Matthew, Stewart and Dan
 
----- Original Message -----
From: "Magnus Ny= str=F6m"=20 <magnusn@gmail.com>
To: &= lt;draft-ietf-mpls= -tp-framework@tools.ietf.org>;=20 <iesg@ietf.org>; <secdir@ietf.org>
Sent: Thursday, = April=20 29, 2010 4:38 AM
Subject: Secdir review of=20 draft-ietf-mpls-tp-framework-11
 

>I have=20 reviewed this document as part of the security directorate's=20
>ongoing  effort to review all IETF documents being processed b= y the=20
>IESG.  These  comments were written primarily for the ben= efit=20 of the
>security area  directors.  Document editors and WG= =20 chairs should treat
>these comments  just  like any other = last=20 call comments.
>
> This document describes the architectural=20 framework for applying MPLS
> to transport networks. It is joint wor= k=20 with the ITU-T.
>
> The document does not contain any normative= =20 statements in the RFC 2119
> sense; presumably this is because the=20 framework nature of the document
> and/or the coupling to ITU-T, but= it=20 is a little concerning as there
> are a number of "must", "should" a= nd=20 "may" statements in the document
> that do look normative to me (e.g= . "In=20 cases where a MAC address is
> needed, the sending node must set the= =20 destination MAC address to an
> address that ensures delivery to the= =20 adjacent node.").
 
The= draft is=20 informational, and therefore should not really include statements
that = look=20 like normative instructions. However, the document has had extensive review= =20
in the ITU and they need some guidance as to some of the normative=20 characteristics
of MPLS-TP. Therefore there are some cases where we have= =20 quoted the relevant requirements
documents and thereofre 'must' appears.= In=20 other cases we propose to change 'must' to
a statement such as 'needs to= '.=20
>
> The security considerations section is very brief and cons= ists=20 mainly
> of references to other, related documents' security=20 considerations sections.
> I
> think it could have been benefic= ial=20 if it had covered security aspects
> stemming from the architectural= =20 framework and not only force the
> reader to turn to the component=20 documents. For example, since G-ACh
> traffic is indistinguishable a= t the=20 server layer from data traffic, is
> it possible to craft data traff= ic=20 messages that confuse a server to believe it is G-ACh?
 
The= se sorts of=20 security considerations are covered by the data plane security discussion=20 referenced from RFC5586->RFC5085 (VCCV).
Sin= ce this is=20 rather an indirect reference, we propose to add the following text, which i= s=20 based on that in RFC5085:
 
" M= PLS-TP nodes=20 that implement the G-ACh create a Control Channel (CC)=20 associated
   with a pseudowire, LSP or section.  This co= ntrol=20 channel can be signaled or
   statically configured.  Ov= er=20 this control channel, control channel messages related
   to= =20 network maintenance functions such as OAM, signaling or network management = are=20 sent. 
   Therefore, three different areas are of concer= n=20 from a security standpoint.
 
&nb= sp;  The=20 first area of concern relates to control plane parameter and
  = ;=20 status message attacks, that is, attacks that concern the=20 signaling
   of G-ACh capabilities.  MPLS-TP Control Plan= e=20 security is discussed in
  =20 [I-D.ietf-mpls-gmpls-security-framework].
 
&nb= sp;  A=20 second area of concern centers on data-plane attacks, that is,
 &nb= sp;=20 attacks on the G-ACh itself.  MPLS-TP nodes that implement=20 the
   G-ACh mechanisms are subject to additional data-plane=20 denial-of-
   service attacks as follows:
 
      An intruder could intercept or = inject=20 G-ACh packets effectively
      disrupting the= =20 protocols carried over the G-ACh.
 
      An intruder could deliberately = flood a=20 peer MPLS-TP node with G-ACh
      messages to = deny=20 services to others.
 
      A misconfigured or misbehaving = device=20 could inadvertently flood a
      peer MPLS-TP = node=20 with G-ACh messages which could result in denial=20 of
      services.  In particular, if a no= de=20 has either implicitly or
      explicitly indic= ated=20 that it cannot support one or all of the
      = types=20 of G-ACh protocol, but is sent those messages in sufficient=20 quantity,
      it could result in a denial of= =20 service.
 
&nb= sp;  To=20 protect against these potential (deliberate or unintentional)
 &nbs= p;=20 attacks, multiple mitigation techniques can be employed:
 
      G-ACh message throttling mechan= isms=20 can be used, especially in
      distributed=20 implementations which have a centralized=20 control-plane
      processor with various line= =20 cards attached by some control-plane
      data= =20 path.  In these architectures, G-ACh messages may be=20 processed
      on the central processor after = being=20 forwarded there by the
      receiving line=20 card.  In this case, the path between the line=20 card
      and the control processor may become= =20 saturated if appropriate G-ACh
      traffic=20 throttling is not employed, which could lead to a=20 complete
      denial of service to users of th= e=20 particular line card.  Such
      filterin= g is=20 also useful for preventing the processing of=20 unwanted
      G-ACh messages, such as those wh= ich=20 are sent on unwanted (and
      perhaps=20 unadvertised) control channel types.
 
&nb= sp;  A=20 third and last area of concern relates to the processing of the
 &n= bsp;=20 actual contents of G-ACh messages. It is necessary that the=20 definition
   of the protocols using these messages carried ov= er a=20 G-ACh include
   appropriate security considerations."<= /DIV>
 
 
 

> Or, does=20 the bandwidth sharing between control traffic and user data
> traffi= c=20 have any security implications?
 
We = have a warning=20 in section 3.6 that sufficient bandwidth needs to be
provisioned to cop= e=20 with the expected G-ACh traffic on = an LSP=20 or PW. However, this could of
course be abused. For example, a malicious or fa= ulty=20 node could inject sufficient traffic
into A G-Ach to cause a DoS on the= =20 control processor of a receiving node. This is
covered in the data plan= e=20 portion of the security considerations text that we propose to insert
(s= ee=20 above).
 
>= ; Also, the NNI=20 traffic may
> involve signaling over the same channel as user data=20 traverse which
> may cause similar concerns (I am not an expert on M= PLS=20 or TP so these
> threats may well not be realistic, however they ser= ve=20 only as
> examples).
>
 
I t= hink that the=20 specific issue of isolation between user and control channel traffic is=20 addressed by
the proposed text above and by existing RFCs dealing with=20 NNI-like applications of MPLS (e.g. RFC5659). 
I t= hink we need to=20 make it clear that when a particular architecture or protocol belonging to = MPLS=20 is profiled for transport,
the= profile=20 inherits the security considerations applicable to MPLS today. I propose th= at we=20 add a statement describing this
to = the start of=20 the security considerations section:
"When an MPLS function is included = in=20 the MPLS transport profile, the security considerations pertinent to
th= at=20 function apply to MPLS-TP."
 

> (A minor=20 editorial suggestion: Perhaps better if the list of acronyms
> in Se= ction=20 1.3 would be in alphabetical order?)
 
Tha= nks. We will=20 reorder the acronyms.
 
 

>
>=20 -- Magnus
>
 
 
--_000_030F37126795E34DB4796609C4FEAA4A127EA83AD1FRMRSSXCHMBSA_-- From paul.hoffman@vpnc.org Tue May 4 17:00:31 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8363B3A6833; Tue, 4 May 2010 17:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.242 X-Spam-Level: ** X-Spam-Status: No, score=2.242 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, HELO_MISMATCH_COM=0.553, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhKZZ14rqQvz; Tue, 4 May 2010 17:00:30 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id ACE763A67DB; Tue, 4 May 2010 17:00:30 -0700 (PDT) Received: from [10.20.30.158] (209-203-104-177.static.twtelecom.net [209.203.104.177]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4500Fcq019031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 17:00:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 4 May 2010 07:59:11 -0700 To: Tom Yu , secdir@ietf.org, iesg@ietf.org, ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-ikev2bis.all@tools.ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [secdir] review of draft-ietf-ipsecme-ikev2bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 00:00:31 -0000 At 1:23 AM -0400 5/4/10, Tom Yu wrote: >draft-ietf-ipsecme-ikev2bis-10 document intends to replace RFC 4306, >the previous specification of IKEv2. My comments focus on the >Security Considerations section, which mostly the same as in RFC 4306. >None of these comments represents a major issue. > >Compared to RFC 4306, the Security Considerations section of this >document contains additional comments about implementation robustness >against attacks (including exhaustion of computational resources) by >unauthenticated peers. > >The following sentence from RFC 4306, referring to Diffie-Hellman >exponents, is not present in this document: > > In particular, these exponents MUST NOT be derived > from long-lived secrets like the seed to a pseudo-random generator > that is not erased after use. > >I understand that this sentence was removed because it is impractical >for many implementations to comply. Correct. > For reasonable interpretations of >the randomness requirements which are listed a few paragraphs later, I >believe it is possible to securely implement this specification >without satisfying the RFC 4306 condition on erasing certain >pseudo-random number generator seeds after use. The paragraph on the >randomness requirements would therefore subsume the above RFC 4306 >condition that was deleted. Do the authors agree? Yes. In particular, the sentence preceding the one that was removed is sufficient: "Achieving perfect forward secrecy requires that when a connection is closed, each endpoint MUST forget not only the keys used by the connection but also any information that could be used to recompute those keys." >The lengthy paragraph warning about non-key-generating EAP methods is >mostly unchanged from RFC 4306. I do wonder if channel bindings would >help with non-key-generating EAP methods tunneled in protected >channels, but am not sufficiently familiar with EAP to know whether >this is feasible. (non-key-generating EAP methods might not have any >way to perform the additional necessary authentication to achieve >channel binding) Channel bindings might or might not help here, depending on the current precise definition of "channel bindings". Trying to wind this into a bis document didn't seem prudent, given the loose state of the definition. >The SHOULD in RFC 4306 in the sentence beginning "Implementers SHOULD >describe the vulnerabilities of non-key-generating EAP methods..." was >demoted to a non-capitalized form. Is this intentional? If so, what >is the rationale? There is no interoperability effect of implementers describing something, and the security aspects are not clear. This seemed like an over-shooting of RFC 2119 language. >This document adds a paragraph about "admission control", a term for >which I am unable to find a contextually meaningful definition. I >agree with the importance of choosing a more carefully evaluated set >of trust anchors for IKE authentication than for identification of >public web servers, but I am uncertain how that statement relates to >(network?) admission control in that paragraph. I think it was meant to indicate that gateways that talk to roaming clients might have different trust requirements than those that only talk to fixed gateways within an organization. >The added section (5.1) on traffic selector authorization seems >reasonable to me. Thanks. >Editorial: > >"elliptical curve" -> "elliptic curve" Good catch. Fixed in the next version. --Paul Hoffman, Director --VPN Consortium From bew@cisco.com Tue May 4 20:22:33 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D167D3A6A73; Tue, 4 May 2010 20:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccQaSaAXmZ-D; Tue, 4 May 2010 20:22:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1DB673A6A3B; Tue, 4 May 2010 20:22:23 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL+A4EurR7Hu/2dsb2JhbACdP3GkfZlXgnWCHgSDPg X-IronPort-AV: E=Sophos;i="4.52,330,1270425600"; d="scan'208";a="525083042" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 05 May 2010 03:22:09 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o453M8mm007376; Wed, 5 May 2010 03:22:09 GMT Message-Id: From: Brian Weis To: Hannes Tschofenig In-Reply-To: <4BDC0A38.20507@gmx.net> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 4 May 2010 20:22:08 -0700 References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> <4BDC0A38.20507@gmx.net> X-Mailer: Apple Mail (2.936) Cc: nsis-chairs@tools.ietf.org, draft-ietf-nsis-rmd@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 03:22:33 -0000 Hi Hannes, On May 1, 2010, at 4:02 AM, Hannes Tschofenig wrote: > Hey Brian, > > thanks for your detailed review. > > I have updated the security consideration section based on your =20 > comments. I have added text to describe security threats in more =20 > detail, discuss what the assumptions are (trust model), provide =20 > security requirements, and updated the part that talks about the =20 > specific solution mechanisms. Thanks! Your re-written security considerations section is very much =20 improved. I do have a couple of comments/questions inline below. > > I also added a sentence about the authorization aspect you =20 > mentioned. There is nothing special about RMD that would require =20 > additional description beyond what is covered in the QoS NSLP and =20 > the solutions we had worked on in the context of the Diameter QoS =20 > application. The authorizatoin aspect largely happens before RMD =20 > signaling is actually triggered. > > My proposed text can be found below (before Georgios adds it to the =20= > draft itself). > > Ciao > Hannes > > --------------- > > > 5. Security Considerations > > I. INTRODUCTION > > A design goal of the RMD-QOSM protocol is to be "lightweight" in terms > of the number of exchanged signaling message and the amount of state > established at involved signaling nodes (with and without reduced > state operation). A side-effect of this design decision is to =20 > introduce > second-class signaling nodes, namely QNE Interior nodes, that are =20 > restricted > in their ability to perform QoS signaling actions. Only the QNE =20 > Ingress and > the QNE Egress nodes are allowed to initiate certain signaling =20 > messages. > Moreover, RMD focuses on an intra-domain deployment only. > > The above description has the following implications for security: > > 1) QNE Ingress and QNE Egress nodes require more security and fault =20= > protection > than QNE Interior nodes because their uncontrolled behavior has larger > implications for the overall stability of the network. > > 2) The focus on intra-domain QoS signaling simplifies trust =20 > management and > reduces overall complexity. See Section 2 of RFC 4081 for a more =20 > detailed > discussion about the complete set of communication models available =20= > for > end-to-end QoS signaling protocols. > > It is important to highlight that RMD always uses the message exchange > shown in Figure 24 > even if there is no end-to-end signaling session. If the RMD-QOSM is > triggered based on an E2E signaling exchange then the RESERVE message > is created by a node outside the RMD domain and will subsequently > travel further on (e.g., to the data receiver). Such an exchange is > shown in Figure 3. As such, an evaluation of RMD's security > always has to be seen as a combination of the two signaling =20 > sessions, (1) > and (2) of Figure 24. > > QNE QNE QNE QNE > Ingress Interior Interior Egress > NTLP stateful NTLP stateless NTLP stateless NTLP stateful > | | | | > | RESERVE (1) | | | > +--------------------------------------------->| > | RESERVE` (2) | | | > +-------------->| | | > | | RESERVE` | | > | +-------------->| | > | | | RESERVE` | > | | +------------->| > | | | RESPONSE` (2)| > |<---------------------------------------------+ > | | | RESPONSE (1) | > |<---------------------------------------------+ > > Figure 24: RMD Message Exchange. > > Authorizing quality of service reservations is accomplished > using the AAA framework and the functionality is inherited from > the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], > and not described again in this document. As a technical > solution mechanism Diameter QoS application > [I-D.ietf-dime-diameter-qos] may be used. I assume that it is implied that this authorization is done by the =20 Ingress router, as opposed to each Interior node in the path. It would =20= be helpful to say this. > > > II. SECURITY THREATS > > In the RMD-QOSM, the ingress node constructs both end-to- > end and intra-domain signaling messages based on the > end-to-end message initiated by the sender end node. The > Interior nodes within the RMD network ignore the end-to-end > signaling message, but process, modify, and forward the intra-domain > signaling messages towards the egress node. In the > meantime, resource reservation states are installed, modified > or deleted at each interior node along the data path according > to the content of each intra-domain signaling message. The > edge nodes of an RMD network are critical components > that require strong security protection. Therefore, they act > as security gateways for incoming and outgoing signaling > messages. Moreover, a certain degree of trust has to be placed > into Interior nodes within the RMD-QOSM network, such that > these nodes can perform signaling message processing and > take the necessary actions. > > With the RMD-QOSM we assume that the > ingress and the egress nodes are not controlled by an adversary > and the communication between the ingress and the egress > nodes is secured using standard GIST security mechanisms Is there a reference for these security mechanisms? > and experiences integrity, replay and confidentiality protection. > Note that this only affects messages directly addressed by > these two nodes and not any other message that needs to > be processed by intermediaries. The SESSION ID object > of the end-to-end communication is visible, via GIST, to the > Interior nodes. > In order to define the security threats that are associated > with the RMD-QOSM we consider that an adversary that may be located > inside the RMD domain and could > drop, delay, duplicate, inject, or modify signaling packets. > Depending on location of adversary, we speak about an on-path > adversary or an off-path adversary, see also RFC 4081 [RFC4081]. > > > II-A. On-path Adversary > > The on-path adversary is a node, which supports RMD-QOSM > and is able to observe RMD-QOSM signaling message > exchanges. > > 1) Dropping signaling messages > > An adversary could drop any signaling messages after > receiving them. This will cause a failure of reservation > request for new sessions or deletion of resource units > (bandwidth) for on-going sessions due to states timeout. > It may trigger the ingress node to retransmit the > lost signaling messages. In this scenario the adversary > drops selected signaling messages, for example intra-domain reserve > messages. In the RMD-QOSM, the retransmission > mechanism can be provided at the ingress node > to make sure that signaling messages can reach the > egress node. However, the retransmissions triggered by > the adversary dropping messages may cause certain > problems. Therefore, it is recommended to disable the use > of retransmissions in the RMD-QOSM aware network. > > 2) Delaying Signaling Messages > > Any signaling message could be delayed by an adversary. > For example, if RESERVE` messages > are delayed over the duration of the refresh period then the =20 > resource units > (bandwidth) reserved along the nodes for corresponding > sessions will be removed. In this situation, the ingress > node does not receive the RESPONSE within a certain > period, and considers that the signaling message is > failed, which may cause a retransmission of the =92failed=92 > message. The egress node may distinguish between the > two messages, i.e., the delayed message and the retransmitted > message, and it could take a proper response. > However, interior nodes suffer from this retransmission > and they may reserve twice the resource units (bandwidth) > requested by the ingress node. Can this threat be generalized from "twice" to "N times", if the =20 message is retransmitted N times? If so, it seems like a serious =20 threat. Can the mitigation for Replayed Signaling Messages (i.e., =20 storing values) be used here. Actually, from the description a =20 retransmitted signaling message seems indistinguishable from a =20 replayed signaling message. > > 3) Replaying Signaling Messages > > An adversary may want to replay signaling messages. > It first stores the > received messages and decides when to replay these > message and at what rate (packets/per seconds). > When the RESERVE` message > carried a RII object, the egress will reply with a > RESPONSE` message towards the ingress node. The ingress > node can then detect replays by comparing the value of > RII in the RESPONSE` messages with the stored value. > > 4) Injecting Signaling Messages > > Similar to the replay-attack scenario, the adversary may > store a part of the information carried by signaling > messages, for example, the RSN object. When the > adversary injects signaling messages, it puts the stored > information together with its own generated parameters > (Bandwidth, RII, etc.) into the injected messages and > then sends them out. Interior nodes will process these > messages by default, reserve the requested resource units > (bandwidth) and pass them to downstream nodes. It > may happen that the resource units (bandwidth) on the > Interior nodes are exhausted if these injected messages > consume much bandwidth. > > 5) Modifying Signaling Messages > > On-path adversaries are capable of modifying any part > of the signaling message. For example, the adversary > can modify the , and parameters > of the RMD-QSPEC messages. The egress node > will then use the SESSION ID and subsequently the > BOUND SESSION ID objects to refer to that flow > to be terminated or set to lower priority. It is also > possible for the adversary to modify the > and/or parameter, which could cause > a modification of an amount of the requested resource > units (bandwidth) changes. Don't interior nodes protect RESERVE` and RESPONSE` messages using hop-=20= by-hop security, or is that just RESERVE and RESPONSE messages? It =20 seems like that would be a simple measure to mitigate threats (4) and =20= (5). > II-B. Off-path Adversary > > In this case the adversary is not located on-path and it > does not participate in the exchange of RMD-QOSM signaling > messages, and therefore is unable to eavesdrop signaling > messages. Hence, the adversary does not know valid RIIs, > RSNs, SESSION IDs. Hence, the adversary has to generate > new parameters and constructs new signaling messages. Since > Interior nodes operate in reduced state mode, > injected signaling messages are treated as new once, which > causes Interior nodes to allocate additional reservation state. > > > III. SECURITY REQUIREMENTS > > The following security requirements are set as goals for the > intra-domain communication, namely: > > * Nodes, which are never supposed to participate in the NSIS signaling > exchange, must not interfere with QNE Interior nodes. Off-path > nodes (off-path with regard to the path taken by a particular > signaling message exchange) must not be able to interfere with > other on-path signaling nodes. > > * The actions allowed by a QNE Interior node should be minimal (i.e., > only those specified by the RMD-QOSM). For example, only the QNE > Ingress and the QNE Egress nodes are allowed to initiate certain > signaling messages. QNE Interior nodes are, for example, allowed to > modify certain signaling message payloads. > > Note that the term `interfere` refers to all sorts of security > threats, such as denial of service, spoofing, replay, signaling > message injection, etc. > > III. SECURITY MECHANISMS Nit: should be "IV." > > An important security mechanism that was > built into RMD-QOSM was the ability to tie the end-to-end > RESERVE and the RESERVE` messages > together using the BOUND SESSION ID and to allow the > ingress node to match the RESERVE` > with the RESPONSE` by using the > RII. These mechanisms enable the edge nodes to detect unexpected > signaling messages. > > We assume that the RESERVE/RESPONSE is sent with hop-by-hop > channel security provided by GIST and protected between the QNE > Ingress and the QNE Egress. If the RESERVE/RESPONSE messages are protected hop-by-hop, why can't =20 RESERVE`/RESPONSE` messages? Or does hop-by-hop mean that only the =20 ingress and egress devices are "hops" and share keys? Thanks, Brian > GIST security mechanisms MUST be used > to offer authentication, > integrity, and replay protection. Furthermore, encryption MUST be used > to > prevent an adversary located along the path of the RESERVE > message to learn information about the session that can later be used > to inject a RESERVE` message. > > The following messages need to be mapped to > each other to make sure that the occurrence of one message is not > without the other one: > > a) the RESERVE and the RESERVE` relate to each other at the QNE > Egress and > > b) the RESPONSE and the RESERVE relate to each other at the QNE > Ingress and > > c) the RESERVE` and the RESPONSE` relate to each other. The RII is > carried in the RESERVE` message and the RESPONSE` message that is > generated by the QNE Egress node contains the same RII as the > RESERVE`. The RII can be used by the QNE Ingress to match the > RESERVE` with the RESPONSE`. The QNE Egress is able to determine > whether the RESERVE` was created by the QNE Ingress node since the > intra-domain session, which sent the RESERVE`, is bound to an end-to- > end session via the BOUND_SESSION_ID value included in the intra- > domain QoS-NSLP operational state maintained at the QNE Egress. > > The RESERVE and the RESERVE` message are tied together using the > BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end > QoS-NSLP operational states maintained at the QNE edges, see Section > 4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a > corresponding RESERVE. The SESSION_ID can fulfill this purpose quite > well if the aim is to provide protection against off-path adversaries > that do not see the SESSION_ID carried in the RESERVE and the > RESERVE` messages. > > If, however, the path changes (due to re-routing or due to mobility) > then an adversary could inject RESERVE` messages (with a previously > seen SESSION_ID) and could potentially cause harm. > > An off-path adversary can, of course, create RESERVE` messages that > cause intermediate nodes to create some state (and cause other > actions) but the message would finally hit the QNE Egress node. The > QNE Egress node would then be able to determine that there is > something going wrong and generate an error message. > > The severe congestion handling can be triggered by intermediate nodes > (unlike other messages). In many cases, however, intermediate nodes > experiencing congestion use refresh messages modify the and > parameters of the message. These messages are still > initiated by the QNE Ingress node and carry the SESSION_ID. The QNE > Egress node will use the SESSION_ID and subsequently the > BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP operational > state, to refer to a flow that might be terminated. The > aspect of intermediate nodes initiating messages for severe > congestion handling is for further study. > > QNE Ingress QNE Interior QNE Interior QNE Egress > NTLP stateful NTLP stateless NTLP stateless NTLP stateful > | | | | > | REFRESH RESERVE` | | > +-------------->| REFRESH RESERVE` | > | (+RII) +-------------->| REFRESH RESERVE` > | | (+RII) +------------->| > | | | (+RII) | > | | | | > | | | REFRESH | > | | | RESPONSE`| > |<---------------------------------------------+ > | | | (+RII) | > > Figure 25: RMD REFRESH message exchange > > During the refresh procedure a RESERVE` creates a RESPONSE`, see > Figure 25. The RII is carried in the RESERVE` message and the > RESPONSE` message that is generated by the QNE Egress node contains > the same RII as the RESERVE`. > > The RII can be used by the QNE Ingress to match the RESERVE` with the > RESPONSE`. > > A further aspect is marking of data traffic. Data packets can be > modified by an intermediary without any relationship to a signaling > session (and a SESSION_ID). The problem appears if an off-path > adversary injects spoofed data packets. > > > The adversary thereby needs to spoof data packets that relate to the > flow identifier of an existing end-to-end reservation that SHOULD be > terminated. Therefore the question arises how an off-path adversary > SHOULD create a data packet that matches an existing flow identifier > (if a 5-tuple is used). Hence, this might not turn out to be simple > for an adversary unless we assume the previously mentioned > mobility/re-routing case where the path through the network changes > and the set of nodes that are along a path changes over time. > > > > > Brian Weis wrote: >> 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 =20 >> treat these comments just like any other last call comments. >> >> This document describes an NSIS QoS Model for networks that use the =20= >> Resource Management in Diffserv (RMD) concept. It describes RMD-=20 >> QOSM, which are new payloads sent using the GISP signaling =20 >> mechanism, where the new payloads request or reserve resources. A =20 >> number of data flows are discussed, depending on whether nodes =20 >> within a network boundary participate in the protocol or not. >> >> The Security Considerations section covers the following topics: >> - Byzantine adversaries (i.e., participants taken over by an =20 >> adversary) are a general problem, but this section intends to =20 >> discuss additional threats as a result of the new protocol. There =20 >> is an extensive discussion of on-path and off-path adversaries, =20 >> which seems to intend to be addressing Byzantine adversaries. >> - RMD-QOSM is claimed to be lightweight, with different routers =20 >> allowed certain operations dependant on the role a router plays in =20= >> the system. E.g., only Ingress/Egress nodes are allowed to initiate =20= >> certain signaling messages. >> - RMD-QOSM "relies on the security support that is provided by the =20= >> bounded end-to-end session, which is running between the boundaries =20= >> of the RMD domain", but doesn't mandate that security support. >> >> The existing text is helpful, but not sufficient. The following =20 >> points are suggestions to improve this section. >> >> 1. The statement at the beginning of Security Considerations =20 >> discusses adversaries taking over a router, but the new threats are =20= >> not very clear. Are the authors considering that security =20 >> associations are revealed, that reservation data routed to a =20 >> particular router can be changed or forged, or something else? >> >> 2. The trust model used by RMD-QOSM is hinted at in the discussion =20= >> of on-path and off-path adversaries, but a discussion of exactly =20 >> what devices are trusted and what they're trusted to do would be =20 >> helpful. For example, is every interior router in the network is =20 >> trusted to handle any particular RESERVE or RESERVE` message? If =20 >> not, then how are the paths setup so that only authorized routers =20 >> will see a particular message? On the other hand, if routing is =20 >> used to route the messages then it would seem that any router must =20= >> be authorized to handle messages happened to be routed to them -- =20 >> but then it isn't clear that there can be a difference between an =20 >> "on-path" and "off-path" adversary. >> >> 3. Another dimension of trust model is the fact that ingress/egress =20= >> routers seem to trust each other more than they trust interior =20 >> nodes. This seems evidenced by the fact that RESERVE messages =20 >> (Figure 24) don't seem to be intended to be modified by the =20 >> interior routers. In the case of probes, I would expect that this =20 >> would be especially important, but probes do not seem to be =20 >> specifically discussed in this section. >> >> 4. There don't seem to be any actual security requirements or =20 >> recommendations made on GIST messaging. As such, it isn't clear =20 >> that attackers that have not taken over a participant (i.e., a man =20= >> in the middle) are in any way foiled. I would expect to see more =20 >> MUSTs and SHOULDs in this section regarding message security. There =20= >> are statements in the I-D such as "In the situation a security =20 >> association exists" and "If we assume that the RESERVE/RESPONSE is =20= >> sent with hop-by-hop channel security". There should be some =20 >> description of the threats to the messaging by a non-participant, =20 >> and stating what available mechanisms MUST or SHOULD be used. >> >> 5. Since roles seem to be an important part of the security =20 >> considerations, it would be helpful to see discussion of the =20 >> different threats & requirements on the ingress/egress routers and =20= >> the internal routers in their different roles. >> >> 6. An important service of RMD-QOSM is admission control, but there =20= >> doesn't seem to be any discussion of how the ingress routers =20 >> determine whether or not reservation requests given to them are =20 >> valid. I would have thought that is of particular importance, but =20 >> if it's considered out of scope this section might mention that fact. > >> >> Hope that helps, >> Brian >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir > --=20 Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From magnusn@gmail.com Tue May 4 21:49:07 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15703A6A99; Tue, 4 May 2010 21:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsScQBvKPxKJ; Tue, 4 May 2010 21:49:06 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id E23C83A6A8A; Tue, 4 May 2010 21:49:05 -0700 (PDT) Received: by yxe9 with SMTP id 9so1685560yxe.29 for ; Tue, 04 May 2010 21:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XzcKMHgq/Ev8tM2GYU4ZETl8r2S+WtACapEs2TeDvxQ=; b=k4uLZCumsMfC0OrKW+BwKmjKl8kZ+s8AxnWoL5+pNcNPIPnMXOhJdDiXbzZzb5V1vQ FDKU1mbtnA9xOl7u0A+y0wD5EFm2OmLDgH7BzyFX5Vs6vSwmDP9RhnlBnqCtlH09UpWT ph0/9udikN4FCfHsIjPXn2uEscfc2oy6F8B1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BnWI1nQDg8wf0Ad5hyLLAPA+B2m6b7rQezd2kFyYp+5MXwrdf47Ssg566CYzzqf+iZ g+KOBQAuG0Q5sPQeQOjtVmO32aEBQ2wOMpSNCLAjUKN5E372LEjsEVXj46iZO6RgVKZA tmbSUyOtDnDSA6kEXUgcLoCuRXFSPNsct/yT4= MIME-Version: 1.0 Received: by 10.101.172.1 with SMTP id z1mr5134859ano.20.1273034928378; Tue, 04 May 2010 21:48:48 -0700 (PDT) Received: by 10.100.124.16 with HTTP; Tue, 4 May 2010 21:48:48 -0700 (PDT) In-Reply-To: <030F37126795E34DB4796609C4FEAA4A127EA83AD1@FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com> References: <030F37126795E34DB4796609C4FEAA4A127EA83AD1@FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com> Date: Tue, 4 May 2010 21:48:48 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "Bocci, Matthew (Matthew)" Content-Type: multipart/alternative; boundary=001636c92539b155c70485d18ab1 Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-mpls-tp-framework@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-tp-framework-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 04:49:07 -0000 --001636c92539b155c70485d18ab1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for your prompt response, Matt (and all). Your suggestions make sense to me and look good to me (perhaps I would suggest that you change " It is necessary that the definition of the protocols using these messages carried over a G-ACh include appropriate security considerations" to " It is necessary that the definition of the protocols using these messages carried over a G-ACh include appropriate security measures" ) Best, -- Magnus On Tue, May 4, 2010 at 3:44 AM, Bocci, Matthew (Matthew) < matthew.bocci@alcatel-lucent.com> wrote: > Magnus, > > Many thanks for your review. Please see below for some responses. > > Best regards, > > Matthew, Stewart and Dan > > ----- Original Message ----- > From: "Magnus Nystr=F6m" > To: ; ; < > secdir@ietf.org> > Sent: Thursday, April 29, 2010 4:38 AM > Subject: Secdir review of draft-ietf-mpls-tp-framework-11 > > > >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 describes the architectural framework for applying MPLS > > to transport networks. It is joint work with the ITU-T. > > > > The document does not contain any normative statements in the RFC 2119 > > sense; presumably this is because the framework nature of the document > > and/or the coupling to ITU-T, but it is a little concerning as there > > are a number of "must", "should" and "may" statements in the document > > that do look normative to me (e.g. "In cases where a MAC address is > > needed, the sending node must set the destination MAC address to an > > address that ensures delivery to the adjacent node."). > > The draft is informational, and therefore should not really include > statements > that look like normative instructions. However, the document has had > extensive review > in the ITU and they need some guidance as to some of the normative > characteristics > of MPLS-TP. Therefore there are some cases where we have quoted the > relevant requirements > documents and thereofre 'must' appears. In other cases we propose to chan= ge > 'must' to > a statement such as 'needs to'. > > > > The security considerations section is very brief and consists mainly > > of references to other, related documents' security considerations > sections. > > I > > think it could have been beneficial if it had covered security aspects > > stemming from the architectural framework and not only force the > > reader to turn to the component documents. For example, since G-ACh > > traffic is indistinguishable at the server layer from data traffic, is > > it possible to craft data traffic messages that confuse a server to > believe it is G-ACh? > > These sorts of security considerations are covered by the data plane > security discussion referenced from RFC5586->RFC5085 (VCCV). > Since this is rather an indirect reference, we propose to add the followi= ng > text, which is based on that in RFC5085: > > " MPLS-TP nodes that implement the G-ACh create a Control Channel (CC) > associated > with a pseudowire, LSP or section. This control channel can be signal= ed > or > statically configured. Over this control channel, control channel > messages related > to network maintenance functions such as OAM, signaling or network > management are sent. > Therefore, three different areas are of concern from a security > standpoint. > > The first area of concern relates to control plane parameter and > status message attacks, that is, attacks that concern the signaling > of G-ACh capabilities. MPLS-TP Control Plane security is discussed in > [I-D.ietf-mpls-gmpls-security-framework]. > > A second area of concern centers on data-plane attacks, that is, > attacks on the G-ACh itself. MPLS-TP nodes that implement the > G-ACh mechanisms are subject to additional data-plane denial-of- > service attacks as follows: > > An intruder could intercept or inject G-ACh packets effectively > disrupting the protocols carried over the G-ACh. > > An intruder could deliberately flood a peer MPLS-TP node with G-ACh > messages to deny services to others. > > A misconfigured or misbehaving device could inadvertently flood a > peer MPLS-TP node with G-ACh messages which could result in denial = of > services. In particular, if a node has either implicitly or > explicitly indicated that it cannot support one or all of the > types of G-ACh protocol, but is sent those messages in sufficient > quantity, > it could result in a denial of service. > > To protect against these potential (deliberate or unintentional) > attacks, multiple mitigation techniques can be employed: > > G-ACh message throttling mechanisms can be used, especially in > distributed implementations which have a centralized control-plane > processor with various line cards attached by some control-plane > data path. In these architectures, G-ACh messages may be processed > on the central processor after being forwarded there by the > receiving line card. In this case, the path between the line card > and the control processor may become saturated if appropriate G-ACh > traffic throttling is not employed, which could lead to a complete > denial of service to users of the particular line card. Such > filtering is also useful for preventing the processing of unwanted > G-ACh messages, such as those which are sent on unwanted (and > perhaps unadvertised) control channel types. > > A third and last area of concern relates to the processing of the > actual contents of G-ACh messages. It is necessary that the definition > of the protocols using these messages carried over a G-ACh include > appropriate security considerations." > > > > > > Or, does the bandwidth sharing between control traffic and user data > > traffic have any security implications? > > We have a warning in section 3.6 that sufficient bandwidth needs to be > provisioned to cope with the expected G-ACh traffic on an LSP or PW. > However, this could of > course be abused. For example, a malicious or faulty node could inject > sufficient traffic > into A G-Ach to cause a DoS on the control processor of a receiving node. > This is > covered in the data plane portion of the security considerations text tha= t > we propose to insert > (see above). > > > Also, the NNI traffic may > > involve signaling over the same channel as user data traverse which > > may cause similar concerns (I am not an expert on MPLS or TP so these > > threats may well not be realistic, however they serve only as > > examples). > > > > I think that the specific issue of isolation between user and control > channel traffic is addressed by > the proposed text above and by existing RFCs dealing with NNI-like > applications of MPLS (e.g. RFC5659). > I think we need to make it clear that when a particular architecture or > protocol belonging to MPLS is profiled for transport, > the profile inherits the security considerations applicable to MPLS today= . > I propose that we add a statement describing this > to the start of the security considerations section: > "When an MPLS function is included in the MPLS transport profile, the > security considerations pertinent to > that function apply to MPLS-TP." > > > > (A minor editorial suggestion: Perhaps better if the list of acronyms > > in Section 1.3 would be in alphabetical order?) > > Thanks. We will reorder the acronyms. > > > > > > > -- Magnus > > > > > --=20 -- Magnus --001636c92539b155c70485d18ab1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for your prompt response, Matt (and all).
Your suggestions make s= ense to me and look good to me

(perhaps I would suggest that you cha= nge

" I= t is necessary that=20 the=20 definition of the protocols using these messages carried over a=20 G-ACh include appropriate security considerations"
t= o
" It is = necessary that=20 the=20 definition of the protocols using these messages carried over a=20 G-ACh include appropriate security measures"
)
Best,
-- Magnus

On Tue, May 4, 2010 a= t 3:44 AM, Bocci, Matthew (Matthew) <matthew.bocci@alcatel-lucent.com>= wrote:
Magnus,
=A0
Many thanks for your review. Please see below for some=20 responses.
=A0
Best regards,
=A0
Matthew, Stewart and Dan
=A0
----- Original Message -----
From: "Magnus Nystr=F6m&q= uot;=20 <magnusn@gmail.co= m>
To: <draft-ietf-mpls-tp-framework@tools.ietf.org&= gt;;=20 <iesg@ietf.org>= ;; <secdir@ietf.org= >
Sent: Thursday, April=20 29, 2010 4:38 AM
Subject: Secdir review of=20 draft-ietf-mpls-tp-framework-11
=A0

>I have=20 reviewed this document as part of the security directorate's=20
>ongoing=A0 effort to review all IETF documents being processed by t= he=20
>IESG.=A0 These=A0 comments were written primarily for the benefit= =20 of the
>security area=A0 directors.=A0 Document editors and WG=20 chairs should treat
>these comments=A0 just=A0 like any other last= =20 call comments.
>
> This document describes the architectural=20 framework for applying MPLS
> to transport networks. It is joint wor= k=20 with the ITU-T.
>
> The document does not contain any normative= =20 statements in the RFC 2119
> sense; presumably this is because the= =20 framework nature of the document
> and/or the coupling to ITU-T, but= it=20 is a little concerning as there
> are a number of "must", = "should" and=20 "may" statements in the document
> that do look normative = to me (e.g. "In=20 cases where a MAC address is
> needed, the sending node must set the= =20 destination MAC address to an
> address that ensures delivery to the= =20 adjacent node.").
=A0
The draft is=20 informational, and therefore should not really include statements
that = look=20 like normative instructions. However, the document has had extensive review= =20
in the ITU and they need some guidance as to some of the normative=20 characteristics
of MPLS-TP. Therefore there are some cases where we have= =20 quoted the relevant requirements
documents and thereofre 'must' = appears. In=20 other cases we propose to change 'must' to
a statement such as &= #39;needs to'.=20
>
> The security considerations section is v= ery brief and consists=20 mainly
> of references to other, related documents' security=20 considerations sections.
> I
> think it could have been benefic= ial=20 if it had covered security aspects
> stemming from the architectural= =20 framework and not only force the
> reader to turn to the component= =20 documents. For example, since G-ACh
> traffic is indistinguishable a= t the=20 server layer from data traffic, is
> it possible to craft data traff= ic=20 messages that confuse a server to believe it is G-ACh?
=A0
These sorts of=20 security considerations are covered by the data plane security discussion= =20 referenced from RFC5586->RFC5085 (VCCV).
Since this is=20 rather an indirect reference, we propose to add the following text, which i= s=20 based on that in RFC5085:
=A0
" MPLS-TP nodes=20 that implement the G-ACh create a Control Channel (CC)=20 associated
=A0=A0 with a pseudowire, LSP or section.=A0 This control=20 channel can be signaled or
=A0=A0 statically configured.=A0 Over=20 this control channel, control channel messages related
=A0=A0 to=20 network maintenance functions such as OAM, signaling or network management = are=20 sent.=A0
=A0=A0 Therefore, three different areas are of concern=20 from a security standpoint.
=A0
=A0=A0 The=20 first area of concern relates to control plane parameter and
=A0=A0=20 status message attacks, that is, attacks that concern the=20 signaling
=A0=A0 of G-ACh capabilities.=A0 MPLS-TP Control Plane=20 security is discussed in
=A0=A0=20 [I-D.ietf-mpls-gmpls-security-framework].
=A0
=A0=A0 A=20 second area of concern centers on data-plane attacks, that is,
=A0=A0=20 attacks on the G-ACh itself.=A0 MPLS-TP nodes that implement=20 the
=A0=A0 G-ACh mechanisms are subject to additional data-plane=20 denial-of-
=A0=A0 service attacks as follows:
=A0
=A0=A0=A0=A0=A0 An intruder could intercept or inject=20 G-ACh packets effectively
=A0=A0=A0=A0=A0 disrupting the=20 protocols carried over the G-ACh.
=A0
=A0=A0=A0=A0=A0 An intruder could deliberately flood a=20 peer MPLS-TP node with G-ACh
=A0=A0=A0=A0=A0 messages to deny=20 services to others.
=A0
=A0=A0=A0=A0=A0 A misconfigured or misbehaving device=20 could inadvertently flood a
=A0=A0=A0=A0=A0 peer MPLS-TP node=20 with G-ACh messages which could result in denial=20 of
=A0=A0=A0=A0=A0 services.=A0 In particular, if a node=20 has either implicitly or
=A0=A0=A0=A0=A0 explicitly indicated=20 that it cannot support one or all of the
=A0=A0=A0=A0=A0 types=20 of G-ACh protocol, but is sent those messages in sufficient=20 quantity,
=A0=A0=A0=A0=A0 it could result in a denial of=20 service.
=A0
=A0=A0 To=20 protect against these potential (deliberate or unintentional)
=A0=A0=20 attacks, multiple mitigation techniques can be employed:
=A0
=A0=A0=A0=A0=A0 G-ACh message throttling mechanisms=20 can be used, especially in
=A0=A0=A0=A0=A0 distributed=20 implementations which have a centralized=20 control-plane
=A0=A0=A0=A0=A0 processor with various line=20 cards attached by some control-plane
=A0=A0=A0=A0=A0 data=20 path.=A0 In these architectures, G-ACh messages may be=20 processed
=A0=A0=A0=A0=A0 on the central processor after being=20 forwarded there by the
=A0=A0=A0=A0=A0 receiving line=20 card.=A0 In this case, the path between the line=20 card
=A0=A0=A0=A0=A0 and the control processor may become=20 saturated if appropriate G-ACh
=A0=A0=A0=A0=A0 traffic=20 throttling is not employed, which could lead to a=20 complete
=A0=A0=A0=A0=A0 denial of service to users of the=20 particular line card.=A0 Such
=A0=A0=A0=A0=A0 filtering is=20 also useful for preventing the processing of=20 unwanted
=A0=A0=A0=A0=A0 G-ACh messages, such as those which=20 are sent on unwanted (and
=A0=A0=A0=A0=A0 perhaps=20 unadvertised) control channel types.
=A0
=A0=A0 A=20 third and last area of concern relates to the processing of the
=A0=A0= =20 actual contents of G-ACh messages. It is necessary that the=20 definition
=A0=A0 of the protocols using these messages carried over a= =20 G-ACh include
=A0=A0 appropriate security considerations."
=A0
=A0
=A0

> Or, does=20 the bandwidth sharing between control traffic and user data
> traffi= c=20 have any security implications?
=A0
We have a warning=20 in section 3.6 that sufficient bandwidth needs to be
provisioned to cop= e=20 with the expected G-ACh traffic on an LSP=20 or PW. However, this could of
course=A0be abused. For exam= ple, a malicious or faulty=20 node could inject sufficient traffic
into A G-Ach to cause a DoS on the= =20 control processor of a receiving node. This is
covered in the data plan= e=20 portion of the security considerations text that we propose to insert
(s= ee=20 above).
=A0
> Also, the NNI=20 traffic may
> involve signaling over the same channel as user data= =20 traverse which
> may cause similar concerns (I am not an expert on M= PLS=20 or TP so these
> threats may well not be realistic, however they ser= ve=20 only as
> examples).
>
=A0
I think that the=20 specific issue of isolation between user and control channel traffic is=20 addressed by
the proposed text above and by existing RFCs dealing with= =20 NNI-like applications of MPLS (e.g. RFC5659).=A0
I think we need to=20 make it clear that when a particular architecture or protocol belonging to = MPLS=20 is profiled for transport,
the profile=20 inherits the security considerations applicable to MPLS today. I propose th= at we=20 add a statement describing this
to the start of=20 the security considerations section:
"When an MPLS function is incl= uded in=20 the MPLS transport profile, the security considerations pertinent to
th= at=20 function apply to MPLS-TP."
=A0

> (A minor=20 editorial suggestion: Perhaps better if the list of acronyms
> in Se= ction=20 1.3 would be in alphabetical order?)
=A0
Thanks. We will=20 reorder the acronyms.
=A0
=A0

>
>=20 -- Magnus
>
=A0
=A0



--
-- Magnus
--001636c92539b155c70485d18ab1-- From magnusn@gmail.com Tue May 4 22:30:37 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3E53A6AF4; Tue, 4 May 2010 22:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X3Q2Uxf3kLs; Tue, 4 May 2010 22:30:33 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 9C7CE28C11B; Tue, 4 May 2010 22:24:12 -0700 (PDT) Received: by gwaa12 with SMTP id a12so2133676gwa.31 for ; Tue, 04 May 2010 22:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=+zpIhC2ROpeVXQo0bmDVGX2a4nBJqPQHnvBZGRxrnYo=; b=LDCpOxJE5qWJRKSi9gU0uKK2Xr62NzgncQPCZNc+eAivKwDWg4d0nFKZxh8PozEDVg 0+cgLn3Hbl1CUSLMlT0fAAcrUp8SXteBJCUyLSK7YPgZsSBm7AEtZA3l8/BW9EBow6kW UlUkHmWa7vLg2s/uyEejJSj5ZydjyEseLoAoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Xu11s6Ciq6tgXFEwmOIPQyuDKDTf6lWoz/6htsKAghqeK5v+AiesLA6CqHCgPGzfcI a3ZeN1kDW0/ajoH8SkcnHxMf2owO5PFxDMmdfrGbPseBoBXVYo+je75B3EeAOQHPCFBU dHd7qGUDjrF10BReTpIVQ5ch8MxGejudD4rvU= MIME-Version: 1.0 Received: by 10.101.198.22 with SMTP id a22mr954013anq.0.1273037012395; Tue, 04 May 2010 22:23:32 -0700 (PDT) Received: by 10.100.124.16 with HTTP; Tue, 4 May 2010 22:23:32 -0700 (PDT) Date: Tue, 4 May 2010 22:23:32 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: secdir@ietf.org, iesg@ietf.org, draft-altmann-tls-channel-bindings@tools.ietf.org Content-Type: multipart/alternative; boundary=0016e6d26d55e8e5c20485d20612 Subject: [secdir] Secdir review of draft-altmann-tls-channel-bindings-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 05:30:37 -0000 --0016e6d26d55e8e5c20485d20612 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 document defines channel binding types for Transport Layer Security (TLS), in accordance with RFC 5056. The review is a follow-up of the review I made back in October 2007. Since then, the unfortunate situation with a delta between an early implementation of the "tls-unique" channel binding and the description in the IANA registration was discovered and this prompted several updates to the draft. As far as I can tell, the current draft solves the issue by adopting the early implementation. It also contains several prominent warnings to implementers about the situation. Two of my comments from my review of -07 still stands: 1. Section 2 should reference RFC 5056, not RFC 5246. This is a bug. 2. It would have been nice with an example of an authentication mechanism using one of the channel bindings in this document, perhaps in the form of an illustrative appendix. -- Magnus --0016e6d26d55e8e5c20485d20612 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. =A0Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines channel binding types for Transport Layer Security (TLS), in accordance with RFC 5056.

The review is a follow-up of the review I made back in October 2007. Since = then, the unfortunate situation with a delta between an early implementatio= n of the "tls-unique" channel binding and the description in the = IANA registration was discovered and this prompted several updates to the d= raft.

As far as I can tell, the current draft solves the issue by adopting th= e early implementation. It also contains several prominent warnings to impl= ementers about the situation.

Two of my comments from my review of -= 07 still stands:

1. Section 2 should reference RFC 5056, not RFC 5246. This is a bug.
2. = It would have been nice with an example of an authentication mechanism usin= g one of the channel bindings in this document, perhaps in the form of an i= llustrative appendix.

-- Magnus

--0016e6d26d55e8e5c20485d20612-- From magnusn@gmail.com Tue May 4 22:43:18 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503F33A6B0D for ; Tue, 4 May 2010 22:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smWz8RlkT+Dw for ; Tue, 4 May 2010 22:43:17 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id 3CD9D3A6B00 for ; Tue, 4 May 2010 22:43:16 -0700 (PDT) Received: by yxe9 with SMTP id 9so1699044yxe.29 for ; Tue, 04 May 2010 22:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=4IHlew6htsk8+A87E07rMtNBtpcLIgim93IaFPMdeL0=; b=VVnaG2UwxclKYjRSbHiEmt0EHOReeSIhSeKjvDUTH7/QjvIaudLcGXCUInOXH7FaPH s/z1iT9i737zQGZI+JyCjQkDzdYwhE7wiXEgnI3W222arfljjXjzLqpq1bGTqoiLhaMR /DkhCpqOZNBG9GtNCoGoqwjzoOJitH/GWFPSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dyCnBwTgAgNmfC7k/B/S2vDK61FF8ATBEfzQWwQJDuC7JDfhceScJNJ1xJOlg0Z7ao ST2pQXD7bZRgRGBZN0lKUDOvrFuOOGKhq4nydCbfY/eSk4ZqGyoo8XyEe/Kw+Zf8X1pG pcDPsEcBjADLsFIJLbC2pBPKfp6G+uEX6E+4s= MIME-Version: 1.0 Received: by 10.100.84.11 with SMTP id h11mr4598515anb.31.1273038179272; Tue, 04 May 2010 22:42:59 -0700 (PDT) Received: by 10.100.124.16 with HTTP; Tue, 4 May 2010 22:42:59 -0700 (PDT) Date: Tue, 4 May 2010 22:42:59 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: draft-altman-tls-channel-bindings@tools.ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary=0016368e1eb2760b990485d24c70 Subject: [secdir] Resend: Secdir review of draft-altman-tls-channel-bindings-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 05:43:18 -0000 --0016368e1eb2760b990485d24c70 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Resend since I used the wrong email address for tools.ietf.org. ---------- Forwarded message ---------- From: Magnus Nystr=F6m Date: Tue, May 4, 2010 at 10:23 PM Subject: Secdir review of draft-altmann-tls-channel-bindings-10 To: secdir@ietf.org, iesg@ietf.org, draft-altmann-tls-channel-bindings@tools.ietf.org 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 channel binding types for Transport Layer Security (TLS), in accordance with RFC 5056. The review is a follow-up of the review I made back in October 2007. Since then, the unfortunate situation with a delta between an early implementatio= n of the "tls-unique" channel binding and the description in the IANA registration was discovered and this prompted several updates to the draft. As far as I can tell, the current draft solves the issue by adopting the early implementation. It also contains several prominent warnings to implementers about the situation. Two of my comments from my review of -07 still stands: 1. Section 2 should reference RFC 5056, not RFC 5246. This is a bug. 2. It would have been nice with an example of an authentication mechanism using one of the channel bindings in this document, perhaps in the form of an illustrative appendix. -- Magnus --=20 -- Magnus --0016368e1eb2760b990485d24c70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Resend since I used the wrong email address for tools.ietf.org.

---------- For= warded message ----------
From: Magnus Nys= tr=F6m <magnu= sn@gmail.com>
Date: Tue, May 4, 2010 at 10:23 PM
Subject: Secdir review of draft-altma= nn-tls-channel-bindings-10
To: secdir= @ietf.org, iesg@ietf.org, draft-altmann= -tls-channel-bindings@tools.ietf.org


I have reviewed this document as part of the security directorate&#= 39;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.

This document defines channel binding types for Transport Layer Security (TLS), in accordance with RFC 5056.

The review is a follow-up of the review I made back in October 2007. Since = then, the unfortunate situation with a delta between an early implementatio= n of the "tls-unique" channel binding and the description in the = IANA registration was discovered and this prompted several updates to the d= raft.

As far as I can tell, the current draft solves the issue by adopting th= e early implementation. It also contains several prominent warnings to impl= ementers about the situation.

Two of my comments from my review of -= 07 still stands:

1. Section 2 should reference RFC 5056, not RFC 5246. This is a bug.
2. = It would have been nice with an example of an authentication mechanism usin= g one of the channel bindings in this document, perhaps in the form of an i= llustrative appendix.

-- Magnus




--
-- Magnus
--0016368e1eb2760b990485d24c70-- From Nicolas.Williams@oracle.com Tue May 4 23:00:52 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C5E3A6AF2 for ; Tue, 4 May 2010 23:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=-1.618, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICYVKZpfq8PX for ; Tue, 4 May 2010 23:00:51 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 664E13A6A60 for ; Tue, 4 May 2010 23:00:51 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4560Uar026465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 May 2010 06:00:32 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o44FRulc029435; Wed, 5 May 2010 06:00:29 GMT Received: from abhmt013.oracle.com by acsmt355.oracle.com with ESMTP id 237548341273039215; Tue, 04 May 2010 23:00:15 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 23:00:14 -0700 Date: Wed, 5 May 2010 01:00:10 -0500 From: Nicolas Williams To: Magnus =?iso-8859-1?Q?Nystr=F6m?= Message-ID: <20100505060009.GV9429@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090207.4BE10980.0156:SCFMA4539811,ss=1,fgs=0 Cc: secdir@ietf.org, draft-altman-tls-channel-bindings@tools.ietf.org Subject: Re: [secdir] Resend: Secdir review of draft-altman-tls-channel-bindings-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 06:00:52 -0000 On Tue, May 04, 2010 at 10:42:59PM -0700, Magnus Nyström 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. Thanks. > Two of my comments from my review of -07 still stands: > > 1. Section 2 should reference RFC 5056, not RFC 5246. This is a bug. Noted many, many times :) There's a note to the RFC-Editor; it will get fixed! > 2. It would have been nice with an example of an authentication mechanism > using one of the channel bindings in this document, perhaps in the form of > an illustrative appendix. Now that SCRAM is on the RFC-Editor queue I suppose we could lift the examples from there and add TLS message descriptions to make a complete example, but I don't really care to provide actual keys, randoms, key derivations, ... -- ENOTENOUGHTIME. We could also do the same with Kerberos, but the examples would be even more opaque. I might draft something, but if it'd require another last call then I'd rather file an I-D, seeking publication as Informational, to provide the examples. Thanks, Nico -- From tena@huawei.com Wed May 5 02:07:01 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EC5B3A6BB6 for ; Wed, 5 May 2010 02:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.588 X-Spam-Level: X-Spam-Status: No, score=-99.588 tagged_above=-999 required=5 tests=[AWL=-1.694, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73xxOYDzLY5d for ; Wed, 5 May 2010 02:07:00 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1F76E3A6BB2 for ; Wed, 5 May 2010 02:06:59 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1X00K62VXMW4@szxga03-in.huawei.com> for secdir@ietf.org; Wed, 05 May 2010 17:05:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1X0007HVXL0L@szxga03-in.huawei.com> for secdir@ietf.org; Wed, 05 May 2010 17:05:45 +0800 (CST) Received: from z00147053k ([10.70.39.52]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1X00B77VXLIZ@szxml06-in.huawei.com> for secdir@ietf.org; Wed, 05 May 2010 17:05:45 +0800 (CST) Date: Wed, 05 May 2010 17:05:45 +0800 From: Tina TSOU To: secdir@ietf.org Message-id: <6D7064749EB54B879A180FADF563D9CA@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: multipart/alternative; boundary="Boundary_(ID_iF816gEVMxYSfzB3pu/kjA)" X-Priority: 3 X-MSMail-priority: Normal Cc: mext-chairs@tools.ietf.org, draft-ietf-mext-flow-binding-06@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-mext-flow-binding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 09:07:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_iF816gEVMxYSfzB3pu/kjA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, 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. Some of my comments are following. Comment 1: The title of this document focuses on flow binding in Mobile IPv6 and NEMO, However it is not clear how flow binding is supported in the NEMO? Is the mobile router operation in NEMO same as mobile node operation in Mobile IPv6? Comment 2: Is flow summary mobility option is one sub-option of Flow Identification Mobility Option or one independent new mobility option? Comment 3: Should the HA, CN and MAP all support this specification? If HA does not support, how to direct inbound flows to specific addresses since one or more flows may bind to a care-of address? B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_iF816gEVMxYSfzB3pu/kjA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,
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.
Some of my comments are following.
 
Comment 1:
The title of this document focuses on flow binding in Mobile IPv6 and NEMO, However it is not clear how flow binding is supported in the NEMO? Is the mobile router operation in NEMO same as mobile node operation in Mobile IPv6?
Comment 2:
Is flow summary mobility option is one sub-option of Flow Identification Mobility Option or one independent new mobility option?
 
Comment 3:
Should the HA, CN and MAP all support this specification? If HA does not support, how to direct inbound flows to specific addresses since one or more flows may bind to a care-of address?
 
 

--Boundary_(ID_iF816gEVMxYSfzB3pu/kjA)-- From tena@huawei.com Wed May 5 02:45:52 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15ED528C0F0 for ; Wed, 5 May 2010 02:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.074 X-Spam-Level: X-Spam-Status: No, score=-98.074 tagged_above=-999 required=5 tests=[AWL=-2.192, BAYES_50=0.001, FAKE_REPLY_C=2.012, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sOUnC8bUSyr for ; Wed, 5 May 2010 02:45:51 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BFE333A6BFB for ; Wed, 5 May 2010 02:45:49 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1X00KCJXRNVF@szxga03-in.huawei.com> for secdir@ietf.org; Wed, 05 May 2010 17:45:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1X0031NXRMU0@szxga03-in.huawei.com> for secdir@ietf.org; Wed, 05 May 2010 17:45:22 +0800 (CST) Received: from z00147053k ([10.70.39.52]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1X00D44XRL7C@szxml06-in.huawei.com> for secdir@ietf.org; Wed, 05 May 2010 17:45:22 +0800 (CST) Date: Wed, 05 May 2010 17:45:21 +0800 From: Tina TSOU To: secdir@ietf.org, draft-ietf-mext-flow-binding@tools.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: multipart/alternative; boundary="Boundary_(ID_uDc75l5alLPwpyqJ8Toojg)" X-Priority: 3 X-MSMail-priority: Normal Cc: mext-chairs@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mext-flow-binding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 09:45:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_uDc75l5alLPwpyqJ8Toojg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Resending to the correct email addresses of the authors... ----- Original Message ----- From: Tina TSOU To: secdir@ietf.org Cc: draft-ietf-mext-flow-binding-06@tools.ietf.org ; mext-chairs@tools.ietf.org Sent: Wednesday, May 05, 2010 5:05 PM Subject: Secdir review of draft-ietf-mext-flow-binding-06 Hi, 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. Some of my comments are following. Comment 1: The title of this document focuses on flow binding in Mobile IPv6 and NEMO, However it is not clear how flow binding is supported in the NEMO? Is the mobile router operation in NEMO same as mobile node operation in Mobile IPv6? Comment 2: Is flow summary mobility option is one sub-option of Flow Identification Mobility Option or one independent new mobility option? Comment 3: Should the HA, CN and MAP all support this specification? If HA does not support, how to direct inbound flows to specific addresses since one or more flows may bind to a care-of address? B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_uDc75l5alLPwpyqJ8Toojg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Resending to the correct email addresses of the authors...
 
----- Original Message -----
From: Tina TSOU
Sent: Wednesday, May 05, 2010 5:05 PM
Subject: Secdir review of draft-ietf-mext-flow-binding-06

Hi,
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.
Some of my comments are following.
 
Comment 1:
The title of this document focuses on flow binding in Mobile IPv6 and NEMO, However it is not clear how flow binding is supported in the NEMO? Is the mobile router operation in NEMO same as mobile node operation in Mobile IPv6?
Comment 2:
Is flow summary mobility option is one sub-option of Flow Identification Mobility Option or one independent new mobility option?
 
Comment 3:
Should the HA, CN and MAP all support this specification? If HA does not support, how to direct inbound flows to specific addresses since one or more flows may bind to a care-of address?
 
 

--Boundary_(ID_uDc75l5alLPwpyqJ8Toojg)-- From Hannes.Tschofenig@gmx.net Wed May 5 11:19:45 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8195B3A6A55 for ; Wed, 5 May 2010 11:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.457 X-Spam-Level: X-Spam-Status: No, score=0.457 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfkmKtMMtOjs for ; Wed, 5 May 2010 11:19:41 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 84A4528C12A for ; Wed, 5 May 2010 11:19:10 -0700 (PDT) Received: (qmail invoked by alias); 05 May 2010 18:18:46 -0000 Received: from wsip-24-120-240-250.lv.lv.cox.net (EHLO [10.186.94.68]) [24.120.240.250] by mail.gmx.net (mp071) with SMTP; 05 May 2010 20:18:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18SI7BlnZwSL8zzVz3ZZL9NptktT+CDLuOkEdjoAq gUO7oRqf2M2GJr Message-ID: <4BE1B678.8020805@gmx.net> Date: Wed, 05 May 2010 11:18:32 -0700 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Weis References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> <4BDC0A38.20507@gmx.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: nsis-chairs@tools.ietf.org, draft-ietf-nsis-rmd@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 18:19:45 -0000 Hi Brian, thanks for the quick response. Brian Weis wrote: > Hi Hannes, > > On May 1, 2010, at 4:02 AM, Hannes Tschofenig wrote: > >> Hey Brian, >> >> thanks for your detailed review. >> >> I have updated the security consideration section based on your >> comments. I have added text to describe security threats in more >> detail, discuss what the assumptions are (trust model), provide >> security requirements, and updated the part that talks about the >> specific solution mechanisms. > > Thanks! Your re-written security considerations section is very much > improved. I do have a couple of comments/questions inline below. > >> >> I also added a sentence about the authorization aspect you mentioned. >> There is nothing special about RMD that would require additional >> description beyond what is covered in the QoS NSLP and the solutions >> we had worked on in the context of the Diameter QoS application. The >> authorizatoin aspect largely happens before RMD signaling is actually >> triggered. >> >> My proposed text can be found below (before Georgios adds it to the >> draft itself). >> >> Ciao >> Hannes >> >> --------------- >> >> >> 5. Security Considerations >> >> I. INTRODUCTION >> >> A design goal of the RMD-QOSM protocol is to be "lightweight" in terms >> of the number of exchanged signaling message and the amount of state >> established at involved signaling nodes (with and without reduced >> state operation). A side-effect of this design decision is to introduce >> second-class signaling nodes, namely QNE Interior nodes, that are >> restricted >> in their ability to perform QoS signaling actions. Only the QNE >> Ingress and >> the QNE Egress nodes are allowed to initiate certain signaling messages. >> Moreover, RMD focuses on an intra-domain deployment only. >> >> The above description has the following implications for security: >> >> 1) QNE Ingress and QNE Egress nodes require more security and fault >> protection >> than QNE Interior nodes because their uncontrolled behavior has larger >> implications for the overall stability of the network. >> >> 2) The focus on intra-domain QoS signaling simplifies trust >> management and >> reduces overall complexity. See Section 2 of RFC 4081 for a more >> detailed >> discussion about the complete set of communication models available for >> end-to-end QoS signaling protocols. >> >> It is important to highlight that RMD always uses the message exchange >> shown in Figure 24 >> even if there is no end-to-end signaling session. If the RMD-QOSM is >> triggered based on an E2E signaling exchange then the RESERVE message >> is created by a node outside the RMD domain and will subsequently >> travel further on (e.g., to the data receiver). Such an exchange is >> shown in Figure 3. As such, an evaluation of RMD's security >> always has to be seen as a combination of the two signaling sessions, >> (1) >> and (2) of Figure 24. >> >> QNE QNE QNE QNE >> Ingress Interior Interior Egress >> NTLP stateful NTLP stateless NTLP stateless NTLP stateful >> | | | | >> | RESERVE (1) | | | >> +--------------------------------------------->| >> | RESERVE` (2) | | | >> +-------------->| | | >> | | RESERVE` | | >> | +-------------->| | >> | | | RESERVE` | >> | | +------------->| >> | | | RESPONSE` (2)| >> |<---------------------------------------------+ >> | | | RESPONSE (1) | >> |<---------------------------------------------+ >> >> Figure 24: RMD Message Exchange. >> >> Authorizing quality of service reservations is accomplished >> using the AAA framework and the functionality is inherited from >> the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], >> and not described again in this document. As a technical >> solution mechanism Diameter QoS application >> [I-D.ietf-dime-diameter-qos] may be used. > > I assume that it is implied that this authorization is done by the > Ingress router, as opposed to each Interior node in the path. It would > be helpful to say this. That's true. I extended the paragraph to: " Authorizing quality of service reservations is accomplished using the AAA framework and the functionality is inherited from the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], and not described again in this document. As a technical solution mechanism Diameter QoS application [I-D.ietf-dime-diameter-qos] may be used. The end-to-end reservation request arriving at the ingress node will trigger the authorization procedure with the backend AAA infrastructure. The end-to-end reservation is typically triggered by a human interaction with a software application, such as a voice-over-IP client when making a call. When authorization is successful then no further user initiated QoS authorization check is expected to be performed within the RMD domain for the intra-domain reservation. " > >> >> >> II. SECURITY THREATS >> >> In the RMD-QOSM, the ingress node constructs both end-to- >> end and intra-domain signaling messages based on the >> end-to-end message initiated by the sender end node. The >> Interior nodes within the RMD network ignore the end-to-end >> signaling message, but process, modify, and forward the intra-domain >> signaling messages towards the egress node. In the >> meantime, resource reservation states are installed, modified >> or deleted at each interior node along the data path according >> to the content of each intra-domain signaling message. The >> edge nodes of an RMD network are critical components >> that require strong security protection. Therefore, they act >> as security gateways for incoming and outgoing signaling >> messages. Moreover, a certain degree of trust has to be placed >> into Interior nodes within the RMD-QOSM network, such that >> these nodes can perform signaling message processing and >> take the necessary actions. >> >> With the RMD-QOSM we assume that the >> ingress and the egress nodes are not controlled by an adversary >> and the communication between the ingress and the egress >> nodes is secured using standard GIST security mechanisms > > Is there a reference for these security mechanisms? > I added a reference to the security consideration section of GIST (Section 6 of [I-D.ietf-nsis-ntlp]).. >> and experiences integrity, replay and confidentiality protection. >> Note that this only affects messages directly addressed by >> these two nodes and not any other message that needs to >> be processed by intermediaries. The SESSION ID object >> of the end-to-end communication is visible, via GIST, to the >> Interior nodes. >> In order to define the security threats that are associated >> with the RMD-QOSM we consider that an adversary that may be located >> inside the RMD domain and could >> drop, delay, duplicate, inject, or modify signaling packets. >> Depending on location of adversary, we speak about an on-path >> adversary or an off-path adversary, see also RFC 4081 [RFC4081]. >> >> >> II-A. On-path Adversary >> >> The on-path adversary is a node, which supports RMD-QOSM >> and is able to observe RMD-QOSM signaling message >> exchanges. >> >> 1) Dropping signaling messages >> >> An adversary could drop any signaling messages after >> receiving them. This will cause a failure of reservation >> request for new sessions or deletion of resource units >> (bandwidth) for on-going sessions due to states timeout. >> It may trigger the ingress node to retransmit the >> lost signaling messages. In this scenario the adversary >> drops selected signaling messages, for example intra-domain reserve >> messages. In the RMD-QOSM, the retransmission >> mechanism can be provided at the ingress node >> to make sure that signaling messages can reach the >> egress node. However, the retransmissions triggered by >> the adversary dropping messages may cause certain >> problems. Therefore, it is recommended to disable the use >> of retransmissions in the RMD-QOSM aware network. >> >> 2) Delaying Signaling Messages >> >> Any signaling message could be delayed by an adversary. >> For example, if RESERVE` messages >> are delayed over the duration of the refresh period then the resource >> units >> (bandwidth) reserved along the nodes for corresponding >> sessions will be removed. In this situation, the ingress >> node does not receive the RESPONSE within a certain >> period, and considers that the signaling message is >> failed, which may cause a retransmission of the ’failed’ >> message. The egress node may distinguish between the >> two messages, i.e., the delayed message and the retransmitted >> message, and it could take a proper response. >> However, interior nodes suffer from this retransmission >> and they may reserve twice the resource units (bandwidth) >> requested by the ingress node. > > Can this threat be generalized from "twice" to "N times", if the > message is retransmitted N times? > If so, it seems like a serious threat. Can the mitigation for Replayed > Signaling Messages (i.e., storing values) be used here. Actually, from > the description a retransmitted signaling message seems > indistinguishable from a replayed signaling message. > For interior nodes it is not possible to distinguish replays. The only entities that detect the replays are edge devices. So, my proposal is to let the egress detect and to alert about the potential problem. >> >> 3) Replaying Signaling Messages >> >> An adversary may want to replay signaling messages. >> It first stores the >> received messages and decides when to replay these >> message and at what rate (packets/per seconds). >> When the RESERVE` message >> carried a RII object, the egress will reply with a >> RESPONSE` message towards the ingress node. The ingress >> node can then detect replays by comparing the value of >> RII in the RESPONSE` messages with the stored value. >> >> 4) Injecting Signaling Messages >> >> Similar to the replay-attack scenario, the adversary may >> store a part of the information carried by signaling >> messages, for example, the RSN object. When the >> adversary injects signaling messages, it puts the stored >> information together with its own generated parameters >> (Bandwidth, RII, etc.) into the injected messages and >> then sends them out. Interior nodes will process these >> messages by default, reserve the requested resource units >> (bandwidth) and pass them to downstream nodes. It >> may happen that the resource units (bandwidth) on the >> Interior nodes are exhausted if these injected messages >> consume much bandwidth. >> >> 5) Modifying Signaling Messages >> >> On-path adversaries are capable of modifying any part >> of the signaling message. For example, the adversary >> can modify the , and parameters >> of the RMD-QSPEC messages. The egress node >> will then use the SESSION ID and subsequently the >> BOUND SESSION ID objects to refer to that flow >> to be terminated or set to lower priority. It is also >> possible for the adversary to modify the >> and/or parameter, which could cause >> a modification of an amount of the requested resource >> units (bandwidth) changes. > > Don't interior nodes protect RESERVE` and RESPONSE` messages using > hop-by-hop security, or is that just RESERVE and RESPONSE messages? > It seems like that would be a simple measure to mitigate threats (4) > and (5). > RESERVE and RESPONSE messages use hop-by-hop security. Keep in mind that for these two messages the "hop" are ingress and egress; for the interior nodes these messages cannot be modified. Using hop-by-hop security for RESERVE` and RESPONSE` messages does not help since the adversary model assumes that one of the interior nodes is acting maliciously. Does this make sense to you? >> II-B. Off-path Adversary >> >> In this case the adversary is not located on-path and it >> does not participate in the exchange of RMD-QOSM signaling >> messages, and therefore is unable to eavesdrop signaling >> messages. Hence, the adversary does not know valid RIIs, >> RSNs, SESSION IDs. Hence, the adversary has to generate >> new parameters and constructs new signaling messages. Since >> Interior nodes operate in reduced state mode, >> injected signaling messages are treated as new once, which >> causes Interior nodes to allocate additional reservation state. >> >> >> III. SECURITY REQUIREMENTS >> >> The following security requirements are set as goals for the >> intra-domain communication, namely: >> >> * Nodes, which are never supposed to participate in the NSIS signaling >> exchange, must not interfere with QNE Interior nodes. Off-path >> nodes (off-path with regard to the path taken by a particular >> signaling message exchange) must not be able to interfere with >> other on-path signaling nodes. >> >> * The actions allowed by a QNE Interior node should be minimal (i.e., >> only those specified by the RMD-QOSM). For example, only the QNE >> Ingress and the QNE Egress nodes are allowed to initiate certain >> signaling messages. QNE Interior nodes are, for example, allowed to >> modify certain signaling message payloads. >> >> Note that the term `interfere` refers to all sorts of security >> threats, such as denial of service, spoofing, replay, signaling >> message injection, etc. >> >> III. SECURITY MECHANISMS > > Nit: should be "IV." Yup. > >> >> An important security mechanism that was >> built into RMD-QOSM was the ability to tie the end-to-end >> RESERVE and the RESERVE` messages >> together using the BOUND SESSION ID and to allow the >> ingress node to match the RESERVE` >> with the RESPONSE` by using the >> RII. These mechanisms enable the edge nodes to detect unexpected >> signaling messages. >> >> We assume that the RESERVE/RESPONSE is sent with hop-by-hop >> channel security provided by GIST and protected between the QNE >> Ingress and the QNE Egress. > > If the RESERVE/RESPONSE messages are protected hop-by-hop, why can't > RESERVE`/RESPONSE` messages? Or does hop-by-hop mean that only the > ingress and egress devices are "hops" and share keys? > See response above. Ciao Hannes > Thanks, > Brian > >> GIST security mechanisms MUST be used >> to offer authentication, >> integrity, and replay protection. Furthermore, encryption MUST be used >> to >> prevent an adversary located along the path of the RESERVE >> message to learn information about the session that can later be used >> to inject a RESERVE` message. >> >> The following messages need to be mapped to >> each other to make sure that the occurrence of one message is not >> without the other one: >> >> a) the RESERVE and the RESERVE` relate to each other at the QNE >> Egress and >> >> b) the RESPONSE and the RESERVE relate to each other at the QNE >> Ingress and >> >> c) the RESERVE` and the RESPONSE` relate to each other. The RII is >> carried in the RESERVE` message and the RESPONSE` message that is >> generated by the QNE Egress node contains the same RII as the >> RESERVE`. The RII can be used by the QNE Ingress to match the >> RESERVE` with the RESPONSE`. The QNE Egress is able to determine >> whether the RESERVE` was created by the QNE Ingress node since the >> intra-domain session, which sent the RESERVE`, is bound to an end-to- >> end session via the BOUND_SESSION_ID value included in the intra- >> domain QoS-NSLP operational state maintained at the QNE Egress. >> >> The RESERVE and the RESERVE` message are tied together using the >> BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end >> QoS-NSLP operational states maintained at the QNE edges, see Section >> 4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a >> corresponding RESERVE. The SESSION_ID can fulfill this purpose quite >> well if the aim is to provide protection against off-path adversaries >> that do not see the SESSION_ID carried in the RESERVE and the >> RESERVE` messages. >> >> If, however, the path changes (due to re-routing or due to mobility) >> then an adversary could inject RESERVE` messages (with a previously >> seen SESSION_ID) and could potentially cause harm. >> >> An off-path adversary can, of course, create RESERVE` messages that >> cause intermediate nodes to create some state (and cause other >> actions) but the message would finally hit the QNE Egress node. The >> QNE Egress node would then be able to determine that there is >> something going wrong and generate an error message. >> >> The severe congestion handling can be triggered by intermediate nodes >> (unlike other messages). In many cases, however, intermediate nodes >> experiencing congestion use refresh messages modify the and >> parameters of the message. These messages are still >> initiated by the QNE Ingress node and carry the SESSION_ID. The QNE >> Egress node will use the SESSION_ID and subsequently the >> BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP operational >> state, to refer to a flow that might be terminated. The >> aspect of intermediate nodes initiating messages for severe >> congestion handling is for further study. >> >> QNE Ingress QNE Interior QNE Interior QNE Egress >> NTLP stateful NTLP stateless NTLP stateless NTLP stateful >> | | | | >> | REFRESH RESERVE` | | >> +-------------->| REFRESH RESERVE` | >> | (+RII) +-------------->| REFRESH RESERVE` >> | | (+RII) +------------->| >> | | | (+RII) | >> | | | | >> | | | REFRESH | >> | | | RESPONSE`| >> |<---------------------------------------------+ >> | | | (+RII) | >> >> Figure 25: RMD REFRESH message exchange >> >> During the refresh procedure a RESERVE` creates a RESPONSE`, see >> Figure 25. The RII is carried in the RESERVE` message and the >> RESPONSE` message that is generated by the QNE Egress node contains >> the same RII as the RESERVE`. >> >> The RII can be used by the QNE Ingress to match the RESERVE` with the >> RESPONSE`. >> >> A further aspect is marking of data traffic. Data packets can be >> modified by an intermediary without any relationship to a signaling >> session (and a SESSION_ID). The problem appears if an off-path >> adversary injects spoofed data packets. >> >> >> The adversary thereby needs to spoof data packets that relate to the >> flow identifier of an existing end-to-end reservation that SHOULD be >> terminated. Therefore the question arises how an off-path adversary >> SHOULD create a data packet that matches an existing flow identifier >> (if a 5-tuple is used). Hence, this might not turn out to be simple >> for an adversary unless we assume the previously mentioned >> mobility/re-routing case where the path through the network changes >> and the set of nodes that are along a path changes over time. >> >> >> >> >> Brian Weis 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. >>> >>> This document describes an NSIS QoS Model for networks that use the >>> Resource Management in Diffserv (RMD) concept. It describes >>> RMD-QOSM, which are new payloads sent using the GISP signaling >>> mechanism, where the new payloads request or reserve resources. A >>> number of data flows are discussed, depending on whether nodes >>> within a network boundary participate in the protocol or not. >>> >>> The Security Considerations section covers the following topics: >>> - Byzantine adversaries (i.e., participants taken over by an >>> adversary) are a general problem, but this section intends to >>> discuss additional threats as a result of the new protocol. There is >>> an extensive discussion of on-path and off-path adversaries, which >>> seems to intend to be addressing Byzantine adversaries. >>> - RMD-QOSM is claimed to be lightweight, with different routers >>> allowed certain operations dependant on the role a router plays in >>> the system. E.g., only Ingress/Egress nodes are allowed to initiate >>> certain signaling messages. >>> - RMD-QOSM "relies on the security support that is provided by the >>> bounded end-to-end session, which is running between the boundaries >>> of the RMD domain", but doesn't mandate that security support. >>> >>> The existing text is helpful, but not sufficient. The following >>> points are suggestions to improve this section. >>> >>> 1. The statement at the beginning of Security Considerations >>> discusses adversaries taking over a router, but the new threats are >>> not very clear. Are the authors considering that security >>> associations are revealed, that reservation data routed to a >>> particular router can be changed or forged, or something else? >>> >>> 2. The trust model used by RMD-QOSM is hinted at in the discussion >>> of on-path and off-path adversaries, but a discussion of exactly >>> what devices are trusted and what they're trusted to do would be >>> helpful. For example, is every interior router in the network is >>> trusted to handle any particular RESERVE or RESERVE` message? If >>> not, then how are the paths setup so that only authorized routers >>> will see a particular message? On the other hand, if routing is used >>> to route the messages then it would seem that any router must be >>> authorized to handle messages happened to be routed to them -- but >>> then it isn't clear that there can be a difference between an >>> "on-path" and "off-path" adversary. >>> >>> 3. Another dimension of trust model is the fact that ingress/egress >>> routers seem to trust each other more than they trust interior >>> nodes. This seems evidenced by the fact that RESERVE messages >>> (Figure 24) don't seem to be intended to be modified by the interior >>> routers. In the case of probes, I would expect that this would be >>> especially important, but probes do not seem to be specifically >>> discussed in this section. >>> >>> 4. There don't seem to be any actual security requirements or >>> recommendations made on GIST messaging. As such, it isn't clear that >>> attackers that have not taken over a participant (i.e., a man in the >>> middle) are in any way foiled. I would expect to see more MUSTs and >>> SHOULDs in this section regarding message security. There are >>> statements in the I-D such as "In the situation a security >>> association exists" and "If we assume that the RESERVE/RESPONSE is >>> sent with hop-by-hop channel security". There should be some >>> description of the threats to the messaging by a non-participant, >>> and stating what available mechanisms MUST or SHOULD be used. >>> >>> 5. Since roles seem to be an important part of the security >>> considerations, it would be helpful to see discussion of the >>> different threats & requirements on the ingress/egress routers and >>> the internal routers in their different roles. >>> >>> 6. An important service of RMD-QOSM is admission control, but there >>> doesn't seem to be any discussion of how the ingress routers >>> determine whether or not reservation requests given to them are >>> valid. I would have thought that is of particular importance, but if >>> it's considered out of scope this section might mention that fact. >> >>> >>> Hope that helps, >>> Brian >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >> > > From bew@cisco.com Wed May 5 12:07:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C9A3A6C67; Wed, 5 May 2010 12:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyG5c5Yk8hCw; Wed, 5 May 2010 12:07:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D172228C151; Wed, 5 May 2010 12:07:06 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP5d4UurR7Ht/2dsb2JhbACdUXGkBplkgnWCHgSDPg X-IronPort-AV: E=Sophos;i="4.52,335,1270425600"; d="scan'208";a="525455813" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 05 May 2010 19:06:53 +0000 Received: from dhcp-128-107-163-73.cisco.com (dhcp-128-107-163-73.cisco.com [128.107.163.73]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o45J6rX9025881; Wed, 5 May 2010 19:06:53 GMT Message-Id: From: Brian Weis To: Hannes Tschofenig In-Reply-To: <4BE1B678.8020805@gmx.net> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 5 May 2010 12:06:51 -0700 References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> <4BDC0A38.20507@gmx.net> <4BE1B678.8020805@gmx.net> X-Mailer: Apple Mail (2.936) Cc: nsis-chairs@tools.ietf.org, draft-ietf-nsis-rmd@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 19:07:15 -0000 Hi Hannes, The expanded authorization paragraph is very clear to me, thanks. Regarding protection of the RESERVE` and RESPONSE` hop-by-hop security: >> Don't interior nodes protect RESERVE` and RESPONSE` messages using =20= >> hop-by-hop security, or is that just RESERVE and RESPONSE =20 >> messages? It seems like that would be a simple measure to mitigate =20= >> threats (4) and (5). >> > RESERVE and RESPONSE messages use hop-by-hop security. Keep in mind =20= > that for these two messages the "hop" are ingress and egress; for =20 > the interior nodes these messages cannot be modified. Thanks for the clarification of what constitutes a "hop". So if I =20 understand correctly, only Ingress and Egress routers share a security =20= association for protecting RESERVE and RESPONSE messages. > Using hop-by-hop security for RESERVE` and RESPONSE` messages does =20 > not help since the adversary model assumes that one of the interior =20= > nodes is acting maliciously. > > Does this make sense to you? My point was that transport security of RESERVE` and RESPONSE` =20 messages between Interior nodes would also be helpful to protect each =20= Interior node from on-path attackers between themselves. I assume they =20= may have adversaries between them. But I think I understand now that the Security Considerations section =20= is written assuming that only Ingress and Egress devices participate =20 in any kind of security association. You're not trusting the Interior =20= nodes at all, so they themselves have no security considerations. =20 Could you please clarify the following points in the INTRODUCTION, =20 which would make that clearer? - What is a "hop" with respect to security associations - The security of RMD-QOSM does not depend on interior nodes. (It does =20= say "The focus on intra-domain QoS signaling simplifies trust =20 management and reduces overall complexity." but that's doesn't really =20= go far enough.) - Because the security of RMD-QOSM does not depend on interior nodes, =20= protection of RESERVE` and RESPONSE` messages is not specified. Thanks, Brian On May 5, 2010, at 11:18 AM, Hannes Tschofenig wrote: > Hi Brian, > > thanks for the quick response. > > Brian Weis wrote: >> Hi Hannes, >> >> On May 1, 2010, at 4:02 AM, Hannes Tschofenig wrote: >> >>> Hey Brian, >>> >>> thanks for your detailed review. >>> >>> I have updated the security consideration section based on your =20 >>> comments. I have added text to describe security threats in more =20 >>> detail, discuss what the assumptions are (trust model), provide =20 >>> security requirements, and updated the part that talks about the =20 >>> specific solution mechanisms. >> >> Thanks! Your re-written security considerations section is very =20 >> much improved. I do have a couple of comments/questions inline below. >> >>> >>> I also added a sentence about the authorization aspect you =20 >>> mentioned. There is nothing special about RMD that would require =20 >>> additional description beyond what is covered in the QoS NSLP and =20= >>> the solutions we had worked on in the context of the Diameter QoS =20= >>> application. The authorizatoin aspect largely happens before RMD =20 >>> signaling is actually triggered. >>> >>> My proposed text can be found below (before Georgios adds it to =20 >>> the draft itself). >>> >>> Ciao >>> Hannes >>> >>> --------------- >>> >>> >>> 5. Security Considerations >>> >>> I. INTRODUCTION >>> >>> A design goal of the RMD-QOSM protocol is to be "lightweight" in =20 >>> terms >>> of the number of exchanged signaling message and the amount of state >>> established at involved signaling nodes (with and without reduced >>> state operation). A side-effect of this design decision is to =20 >>> introduce >>> second-class signaling nodes, namely QNE Interior nodes, that are =20= >>> restricted >>> in their ability to perform QoS signaling actions. Only the QNE =20 >>> Ingress and >>> the QNE Egress nodes are allowed to initiate certain signaling =20 >>> messages. >>> Moreover, RMD focuses on an intra-domain deployment only. >>> >>> The above description has the following implications for security: >>> >>> 1) QNE Ingress and QNE Egress nodes require more security and =20 >>> fault protection >>> than QNE Interior nodes because their uncontrolled behavior has =20 >>> larger >>> implications for the overall stability of the network. >>> >>> 2) The focus on intra-domain QoS signaling simplifies trust =20 >>> management and >>> reduces overall complexity. See Section 2 of RFC 4081 for a more =20 >>> detailed >>> discussion about the complete set of communication models =20 >>> available for >>> end-to-end QoS signaling protocols. >>> >>> It is important to highlight that RMD always uses the message =20 >>> exchange >>> shown in Figure 24 >>> even if there is no end-to-end signaling session. If the RMD-QOSM is >>> triggered based on an E2E signaling exchange then the RESERVE =20 >>> message >>> is created by a node outside the RMD domain and will subsequently >>> travel further on (e.g., to the data receiver). Such an exchange is >>> shown in Figure 3. As such, an evaluation of RMD's security >>> always has to be seen as a combination of the two signaling =20 >>> sessions, (1) >>> and (2) of Figure 24. >>> >>> QNE QNE QNE QNE >>> Ingress Interior Interior Egress >>> NTLP stateful NTLP stateless NTLP stateless NTLP stateful >>> | | | | >>> | RESERVE (1) | | | >>> +--------------------------------------------->| >>> | RESERVE` (2) | | | >>> +-------------->| | | >>> | | RESERVE` | | >>> | +-------------->| | >>> | | | RESERVE` | >>> | | +------------->| >>> | | | RESPONSE` (2)| >>> |<---------------------------------------------+ >>> | | | RESPONSE (1) | >>> |<---------------------------------------------+ >>> >>> Figure 24: RMD Message Exchange. >>> >>> Authorizing quality of service reservations is accomplished >>> using the AAA framework and the functionality is inherited from >>> the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], >>> and not described again in this document. As a technical >>> solution mechanism Diameter QoS application >>> [I-D.ietf-dime-diameter-qos] may be used. >> >> I assume that it is implied that this authorization is done by the =20= >> Ingress router, as opposed to each Interior node in the path. It =20 >> would be helpful to say this. > > That's true. I extended the paragraph to: > > " > Authorizing quality of service reservations is accomplished > using the AAA framework and the functionality is inherited from > the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], > and not described again in this document. As a technical > solution mechanism Diameter QoS application > [I-D.ietf-dime-diameter-qos] may be used. The end-to-end > reservation request arriving at the ingress node will > trigger the authorization procedure with the backend AAA > infrastructure. The end-to-end reservation is typically > triggered by a human interaction with a software application, > such as a voice-over-IP client when making a call. When > authorization is successful then no further user initiated > QoS authorization check is expected to be performed within > the RMD domain for the intra-domain reservation. > " > >> >>> >>> >>> II. SECURITY THREATS >>> >>> In the RMD-QOSM, the ingress node constructs both end-to- >>> end and intra-domain signaling messages based on the >>> end-to-end message initiated by the sender end node. The >>> Interior nodes within the RMD network ignore the end-to-end >>> signaling message, but process, modify, and forward the intra-domain >>> signaling messages towards the egress node. In the >>> meantime, resource reservation states are installed, modified >>> or deleted at each interior node along the data path according >>> to the content of each intra-domain signaling message. The >>> edge nodes of an RMD network are critical components >>> that require strong security protection. Therefore, they act >>> as security gateways for incoming and outgoing signaling >>> messages. Moreover, a certain degree of trust has to be placed >>> into Interior nodes within the RMD-QOSM network, such that >>> these nodes can perform signaling message processing and >>> take the necessary actions. >>> >>> With the RMD-QOSM we assume that the >>> ingress and the egress nodes are not controlled by an adversary >>> and the communication between the ingress and the egress >>> nodes is secured using standard GIST security mechanisms >> >> Is there a reference for these security mechanisms? >> > I added a reference to the security consideration section of GIST =20 > (Section 6 of [I-D.ietf-nsis-ntlp]).. > >>> and experiences integrity, replay and confidentiality protection. >>> Note that this only affects messages directly addressed by >>> these two nodes and not any other message that needs to >>> be processed by intermediaries. The SESSION ID object >>> of the end-to-end communication is visible, via GIST, to the >>> Interior nodes. >>> In order to define the security threats that are associated >>> with the RMD-QOSM we consider that an adversary that may be located >>> inside the RMD domain and could >>> drop, delay, duplicate, inject, or modify signaling packets. >>> Depending on location of adversary, we speak about an on-path >>> adversary or an off-path adversary, see also RFC 4081 [RFC4081]. >>> >>> >>> II-A. On-path Adversary >>> >>> The on-path adversary is a node, which supports RMD-QOSM >>> and is able to observe RMD-QOSM signaling message >>> exchanges. >>> >>> 1) Dropping signaling messages >>> >>> An adversary could drop any signaling messages after >>> receiving them. This will cause a failure of reservation >>> request for new sessions or deletion of resource units >>> (bandwidth) for on-going sessions due to states timeout. >>> It may trigger the ingress node to retransmit the >>> lost signaling messages. In this scenario the adversary >>> drops selected signaling messages, for example intra-domain reserve >>> messages. In the RMD-QOSM, the retransmission >>> mechanism can be provided at the ingress node >>> to make sure that signaling messages can reach the >>> egress node. However, the retransmissions triggered by >>> the adversary dropping messages may cause certain >>> problems. Therefore, it is recommended to disable the use >>> of retransmissions in the RMD-QOSM aware network. >>> >>> 2) Delaying Signaling Messages >>> >>> Any signaling message could be delayed by an adversary. >>> For example, if RESERVE` messages >>> are delayed over the duration of the refresh period then the =20 >>> resource units >>> (bandwidth) reserved along the nodes for corresponding >>> sessions will be removed. In this situation, the ingress >>> node does not receive the RESPONSE within a certain >>> period, and considers that the signaling message is >>> failed, which may cause a retransmission of the =92failed=92 >>> message. The egress node may distinguish between the >>> two messages, i.e., the delayed message and the retransmitted >>> message, and it could take a proper response. >>> However, interior nodes suffer from this retransmission >>> and they may reserve twice the resource units (bandwidth) >>> requested by the ingress node. >> >> Can this threat be generalized from "twice" to "N times", if the =20 >> message is retransmitted N times? >> If so, it seems like a serious threat. Can the mitigation for =20 >> Replayed Signaling Messages (i.e., storing values) be used here. =20 >> Actually, from the description a retransmitted signaling message =20 >> seems indistinguishable from a replayed signaling message. >> > For interior nodes it is not possible to distinguish replays. The =20 > only entities that detect the replays are edge devices. So, my =20 > proposal is to let the egress detect and to alert about the =20 > potential problem. > > >>> >>> 3) Replaying Signaling Messages >>> >>> An adversary may want to replay signaling messages. >>> It first stores the >>> received messages and decides when to replay these >>> message and at what rate (packets/per seconds). >>> When the RESERVE` message >>> carried a RII object, the egress will reply with a >>> RESPONSE` message towards the ingress node. The ingress >>> node can then detect replays by comparing the value of >>> RII in the RESPONSE` messages with the stored value. >>> >>> 4) Injecting Signaling Messages >>> >>> Similar to the replay-attack scenario, the adversary may >>> store a part of the information carried by signaling >>> messages, for example, the RSN object. When the >>> adversary injects signaling messages, it puts the stored >>> information together with its own generated parameters >>> (Bandwidth, RII, etc.) into the injected messages and >>> then sends them out. Interior nodes will process these >>> messages by default, reserve the requested resource units >>> (bandwidth) and pass them to downstream nodes. It >>> may happen that the resource units (bandwidth) on the >>> Interior nodes are exhausted if these injected messages >>> consume much bandwidth. >>> >>> 5) Modifying Signaling Messages >>> >>> On-path adversaries are capable of modifying any part >>> of the signaling message. For example, the adversary >>> can modify the , and parameters >>> of the RMD-QSPEC messages. The egress node >>> will then use the SESSION ID and subsequently the >>> BOUND SESSION ID objects to refer to that flow >>> to be terminated or set to lower priority. It is also >>> possible for the adversary to modify the >>> and/or parameter, which could cause >>> a modification of an amount of the requested resource >>> units (bandwidth) changes. >> >> Don't interior nodes protect RESERVE` and RESPONSE` messages using =20= >> hop-by-hop security, or is that just RESERVE and RESPONSE =20 >> messages? It seems like that would be a simple measure to mitigate =20= >> threats (4) and (5). >> > RESERVE and RESPONSE messages use hop-by-hop security. Keep in mind =20= > that for these two messages the "hop" are ingress and egress; for =20 > the interior nodes these messages cannot be modified. > > Using hop-by-hop security for RESERVE` and RESPONSE` messages does =20 > not help since the adversary model assumes that one of the interior =20= > nodes is acting maliciously. > > Does this make sense to you? > >>> II-B. Off-path Adversary >>> >>> In this case the adversary is not located on-path and it >>> does not participate in the exchange of RMD-QOSM signaling >>> messages, and therefore is unable to eavesdrop signaling >>> messages. Hence, the adversary does not know valid RIIs, >>> RSNs, SESSION IDs. Hence, the adversary has to generate >>> new parameters and constructs new signaling messages. Since >>> Interior nodes operate in reduced state mode, >>> injected signaling messages are treated as new once, which >>> causes Interior nodes to allocate additional reservation state. >>> >>> >>> III. SECURITY REQUIREMENTS >>> >>> The following security requirements are set as goals for the >>> intra-domain communication, namely: >>> >>> * Nodes, which are never supposed to participate in the NSIS =20 >>> signaling >>> exchange, must not interfere with QNE Interior nodes. Off-path >>> nodes (off-path with regard to the path taken by a particular >>> signaling message exchange) must not be able to interfere with >>> other on-path signaling nodes. >>> >>> * The actions allowed by a QNE Interior node should be minimal =20 >>> (i.e., >>> only those specified by the RMD-QOSM). For example, only the QNE >>> Ingress and the QNE Egress nodes are allowed to initiate certain >>> signaling messages. QNE Interior nodes are, for example, allowed to >>> modify certain signaling message payloads. >>> >>> Note that the term `interfere` refers to all sorts of security >>> threats, such as denial of service, spoofing, replay, signaling >>> message injection, etc. >>> >>> III. SECURITY MECHANISMS >> >> Nit: should be "IV." > Yup. > >> >>> >>> An important security mechanism that was >>> built into RMD-QOSM was the ability to tie the end-to-end >>> RESERVE and the RESERVE` messages >>> together using the BOUND SESSION ID and to allow the >>> ingress node to match the RESERVE` >>> with the RESPONSE` by using the >>> RII. These mechanisms enable the edge nodes to detect unexpected >>> signaling messages. >>> >>> We assume that the RESERVE/RESPONSE is sent with hop-by-hop >>> channel security provided by GIST and protected between the QNE >>> Ingress and the QNE Egress. >> >> If the RESERVE/RESPONSE messages are protected hop-by-hop, why =20 >> can't RESERVE`/RESPONSE` messages? Or does hop-by-hop mean that =20 >> only the ingress and egress devices are "hops" and share keys? >> > See response above. > > Ciao > Hannes > >> Thanks, >> Brian >> >>> GIST security mechanisms MUST be used >>> to offer authentication, >>> integrity, and replay protection. Furthermore, encryption MUST be =20= >>> used >>> to >>> prevent an adversary located along the path of the RESERVE >>> message to learn information about the session that can later be =20 >>> used >>> to inject a RESERVE` message. >>> >>> The following messages need to be mapped to >>> each other to make sure that the occurrence of one message is not >>> without the other one: >>> >>> a) the RESERVE and the RESERVE` relate to each other at the QNE >>> Egress and >>> >>> b) the RESPONSE and the RESERVE relate to each other at the QNE >>> Ingress and >>> >>> c) the RESERVE` and the RESPONSE` relate to each other. The RII is >>> carried in the RESERVE` message and the RESPONSE` message that is >>> generated by the QNE Egress node contains the same RII as the >>> RESERVE`. The RII can be used by the QNE Ingress to match the >>> RESERVE` with the RESPONSE`. The QNE Egress is able to determine >>> whether the RESERVE` was created by the QNE Ingress node since the >>> intra-domain session, which sent the RESERVE`, is bound to an end-=20= >>> to- >>> end session via the BOUND_SESSION_ID value included in the intra- >>> domain QoS-NSLP operational state maintained at the QNE Egress. >>> >>> The RESERVE and the RESERVE` message are tied together using the >>> BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end >>> QoS-NSLP operational states maintained at the QNE edges, see Section >>> 4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a >>> corresponding RESERVE. The SESSION_ID can fulfill this purpose quite >>> well if the aim is to provide protection against off-path =20 >>> adversaries >>> that do not see the SESSION_ID carried in the RESERVE and the >>> RESERVE` messages. >>> >>> If, however, the path changes (due to re-routing or due to mobility) >>> then an adversary could inject RESERVE` messages (with a previously >>> seen SESSION_ID) and could potentially cause harm. >>> >>> An off-path adversary can, of course, create RESERVE` messages that >>> cause intermediate nodes to create some state (and cause other >>> actions) but the message would finally hit the QNE Egress node. The >>> QNE Egress node would then be able to determine that there is >>> something going wrong and generate an error message. >>> >>> The severe congestion handling can be triggered by intermediate =20 >>> nodes >>> (unlike other messages). In many cases, however, intermediate nodes >>> experiencing congestion use refresh messages modify the and >>> parameters of the message. These messages are still >>> initiated by the QNE Ingress node and carry the SESSION_ID. The QNE >>> Egress node will use the SESSION_ID and subsequently the >>> BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP =20 >>> operational >>> state, to refer to a flow that might be terminated. The >>> aspect of intermediate nodes initiating messages for severe >>> congestion handling is for further study. >>> >>> QNE Ingress QNE Interior QNE Interior QNE Egress >>> NTLP stateful NTLP stateless NTLP stateless NTLP stateful >>> | | | | >>> | REFRESH RESERVE` | | >>> +-------------->| REFRESH RESERVE` | >>> | (+RII) +-------------->| REFRESH RESERVE` >>> | | (+RII) +------------->| >>> | | | (+RII) | >>> | | | | >>> | | | REFRESH | >>> | | | RESPONSE`| >>> |<---------------------------------------------+ >>> | | | (+RII) | >>> >>> Figure 25: RMD REFRESH message exchange >>> >>> During the refresh procedure a RESERVE` creates a RESPONSE`, see >>> Figure 25. The RII is carried in the RESERVE` message and the >>> RESPONSE` message that is generated by the QNE Egress node contains >>> the same RII as the RESERVE`. >>> >>> The RII can be used by the QNE Ingress to match the RESERVE` with =20= >>> the >>> RESPONSE`. >>> >>> A further aspect is marking of data traffic. Data packets can be >>> modified by an intermediary without any relationship to a signaling >>> session (and a SESSION_ID). The problem appears if an off-path >>> adversary injects spoofed data packets. >>> >>> >>> The adversary thereby needs to spoof data packets that relate to the >>> flow identifier of an existing end-to-end reservation that SHOULD be >>> terminated. Therefore the question arises how an off-path adversary >>> SHOULD create a data packet that matches an existing flow identifier >>> (if a 5-tuple is used). Hence, this might not turn out to be simple >>> for an adversary unless we assume the previously mentioned >>> mobility/re-routing case where the path through the network changes >>> and the set of nodes that are along a path changes over time. >>> >>> >>> >>> >>> Brian Weis wrote: >>>> I have reviewed this document as part of the security =20 >>>> directorate's ongoing effort to review all IETF documents being =20 >>>> processed by the IESG. These comments were written primarily for =20= >>>> the benefit of the security area directors. Document editors and =20= >>>> WG chairs should treat these comments just like any other last =20 >>>> call comments. >>>> >>>> This document describes an NSIS QoS Model for networks that use =20 >>>> the Resource Management in Diffserv (RMD) concept. It describes =20 >>>> RMD-QOSM, which are new payloads sent using the GISP signaling =20 >>>> mechanism, where the new payloads request or reserve resources. A =20= >>>> number of data flows are discussed, depending on whether nodes =20 >>>> within a network boundary participate in the protocol or not. >>>> >>>> The Security Considerations section covers the following topics: >>>> - Byzantine adversaries (i.e., participants taken over by an =20 >>>> adversary) are a general problem, but this section intends to =20 >>>> discuss additional threats as a result of the new protocol. There =20= >>>> is an extensive discussion of on-path and off-path adversaries, =20 >>>> which seems to intend to be addressing Byzantine adversaries. >>>> - RMD-QOSM is claimed to be lightweight, with different routers =20 >>>> allowed certain operations dependant on the role a router plays =20 >>>> in the system. E.g., only Ingress/Egress nodes are allowed to =20 >>>> initiate certain signaling messages. >>>> - RMD-QOSM "relies on the security support that is provided by =20 >>>> the bounded end-to-end session, which is running between the =20 >>>> boundaries of the RMD domain", but doesn't mandate that security =20= >>>> support. >>>> >>>> The existing text is helpful, but not sufficient. The following =20 >>>> points are suggestions to improve this section. >>>> >>>> 1. The statement at the beginning of Security Considerations =20 >>>> discusses adversaries taking over a router, but the new threats =20 >>>> are not very clear. Are the authors considering that security =20 >>>> associations are revealed, that reservation data routed to a =20 >>>> particular router can be changed or forged, or something else? >>>> >>>> 2. The trust model used by RMD-QOSM is hinted at in the =20 >>>> discussion of on-path and off-path adversaries, but a discussion =20= >>>> of exactly what devices are trusted and what they're trusted to =20 >>>> do would be helpful. For example, is every interior router in the =20= >>>> network is trusted to handle any particular RESERVE or RESERVE` =20 >>>> message? If not, then how are the paths setup so that only =20 >>>> authorized routers will see a particular message? On the other =20 >>>> hand, if routing is used to route the messages then it would seem =20= >>>> that any router must be authorized to handle messages happened to =20= >>>> be routed to them -- but then it isn't clear that there can be a =20= >>>> difference between an "on-path" and "off-path" adversary. >>>> >>>> 3. Another dimension of trust model is the fact that ingress/=20 >>>> egress routers seem to trust each other more than they trust =20 >>>> interior nodes. This seems evidenced by the fact that RESERVE =20 >>>> messages (Figure 24) don't seem to be intended to be modified by =20= >>>> the interior routers. In the case of probes, I would expect that =20= >>>> this would be especially important, but probes do not seem to be =20= >>>> specifically discussed in this section. >>>> >>>> 4. There don't seem to be any actual security requirements or =20 >>>> recommendations made on GIST messaging. As such, it isn't clear =20 >>>> that attackers that have not taken over a participant (i.e., a =20 >>>> man in the middle) are in any way foiled. I would expect to see =20 >>>> more MUSTs and SHOULDs in this section regarding message =20 >>>> security. There are statements in the I-D such as "In the =20 >>>> situation a security association exists" and "If we assume that =20 >>>> the RESERVE/RESPONSE is sent with hop-by-hop channel security". =20 >>>> There should be some description of the threats to the messaging =20= >>>> by a non-participant, and stating what available mechanisms MUST =20= >>>> or SHOULD be used. >>>> >>>> 5. Since roles seem to be an important part of the security =20 >>>> considerations, it would be helpful to see discussion of the =20 >>>> different threats & requirements on the ingress/egress routers =20 >>>> and the internal routers in their different roles. >>>> >>>> 6. An important service of RMD-QOSM is admission control, but =20 >>>> there doesn't seem to be any discussion of how the ingress =20 >>>> routers determine whether or not reservation requests given to =20 >>>> them are valid. I would have thought that is of particular =20 >>>> importance, but if it's considered out of scope this section =20 >>>> might mention that fact. >>> >>>> >>>> Hope that helps, >>>> Brian >>>> _______________________________________________ >>>> secdir mailing list >>>> secdir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdir >>> >> >> > --=20 Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From Hannes.Tschofenig@gmx.net Wed May 5 15:02:36 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7353A6D2F for ; Wed, 5 May 2010 15:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=1.665, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEHjXhDH-0t0 for ; Wed, 5 May 2010 15:02:36 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3355A3A6D32 for ; Wed, 5 May 2010 15:02:32 -0700 (PDT) Received: (qmail invoked by alias); 05 May 2010 22:02:18 -0000 Received: from wsip-24-120-240-250.lv.lv.cox.net (EHLO [10.186.94.68]) [24.120.240.250] by mail.gmx.net (mp071) with SMTP; 06 May 2010 00:02:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Fqgt8UReF6iXe56QkBlk3KUObf7gPMIrK8mE+HM LuoKGw+/LnY1Fy Message-ID: <4BE1EAE3.6030304@gmx.net> Date: Wed, 05 May 2010 15:02:11 -0700 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Weis References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> <4BDC0A38.20507@gmx.net> <4BE1B678.8020805@gmx.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: nsis-chairs@tools.ietf.org, draft-ietf-nsis-rmd@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 22:02:36 -0000 Hi Brian, Brian Weis wrote: > Hi Hannes, > > The expanded authorization paragraph is very clear to me, thanks. > > Regarding protection of the RESERVE` and RESPONSE` hop-by-hop security: > >>> Don't interior nodes protect RESERVE` and RESPONSE` messages using >>> hop-by-hop security, or is that just RESERVE and RESPONSE messages? >>> It seems like that would be a simple measure to mitigate threats >>> (4) and (5). >>> >> RESERVE and RESPONSE messages use hop-by-hop security. Keep in mind >> that for these two messages the "hop" are ingress and egress; for the >> interior nodes these messages cannot be modified. > > Thanks for the clarification of what constitutes a "hop". So if I > understand correctly, only Ingress and Egress routers share a security > association for protecting RESERVE and RESPONSE messages. Yes. > >> Using hop-by-hop security for RESERVE` and RESPONSE` messages does >> not help since the adversary model assumes that one of the interior >> nodes is acting maliciously. >> >> Does this make sense to you? > > > My point was that transport security of RESERVE` and RESPONSE` > messages between Interior nodes would also be helpful to protect each > Interior node from on-path attackers between themselves. I assume they > may have adversaries between them. Well. There is actually no other entity between the participating interior nodes. In RMD all the nodes in the domain have to participate. > > But I think I understand now that the Security Considerations section > is written assuming that only Ingress and Egress devices participate > in any kind of security association. Yes. > You're not trusting the Interior nodes at all, so they themselves have > no security considerations. Normally, with a QoS signaling protocol you have to essentially trust every node that understands the protocol. In RMD I thought that it would be interesting to exploit the fact that you can do better than that. > Could you please clarify the following points in the INTRODUCTION, > which would make that clearer? > - What is a "hop" with respect to security associations > - The security of RMD-QOSM does not depend on interior nodes. (It does > say "The focus on intra-domain QoS signaling simplifies trust > management and reduces overall complexity." but that's doesn't really > go far enough.) > - Because the security of RMD-QOSM does not depend on interior nodes, > protection of RESERVE` and RESPONSE` messages is not specified. > Sure. Makes sense. Here is my proposal: I. INTRODUCTION A design goal of the RMD-QOSM protocol is to be "lightweight" in terms of the number of exchanged signaling message and the amount of state established at involved signaling nodes (with and without reduced state operation). A side-effect of this design decision is to introduce second-class signaling nodes, namely QNE Interior nodes, that are restricted in their ability to perform QoS signaling actions. Only the QNE Ingress and the QNE Egress nodes are allowed to initiate certain signaling messages. Moreover, RMD focuses on an intra-domain deployment only. The above description has the following implications for security: 1) QNE Ingress and QNE Egress nodes require more security and fault protection than QNE Interior nodes because their uncontrolled behavior has larger implications for the overall stability of the network. QNE Ingress and QNE Egress nodes share a security association and utlize GIST security for protection of their signaling messages. Intra-domain signaling messages used for RMD signaling do not use GIST security and therefore they do not store security associations. 2) The focus on intra-domain QoS signaling simplifies trust management and reduces overall complexity. See Section 2 of RFC 4081 for a more detailed discussion about the complete set of communication models available for end-to-end QoS signaling protocols. The security of RMD-QOSM does not depend on interior nodes and hence the cryptographic protection of intra-domain messages via GIST is not utilized. It is important to highlight that RMD always uses the message exchange shown in Figure 24 even if there is no end-to-end signaling session. If the RMD-QOSM is triggered based on an E2E signaling exchange then the RESERVE message is created by a node outside the RMD domain and will subsequently travel further on (e.g., to the data receiver). Such an exchange is shown in Figure 3. As such, an evaluation of RMD's security always has to be seen as a combination of the two signaling sessions, (1) and (2) of Figure 24. Note that for the E2E message, such as the RESERVE and the RESPONSE message, a single "hop" refers to the communication between the QNE Ingress and the QNE Egress since QNE Interior nodes do not participate in the exchange. Ciao Hannes > Thanks, > Brian > > On May 5, 2010, at 11:18 AM, Hannes Tschofenig wrote: > >> Hi Brian, >> >> thanks for the quick response. >> >> Brian Weis wrote: >>> Hi Hannes, >>> >>> On May 1, 2010, at 4:02 AM, Hannes Tschofenig wrote: >>> >>>> Hey Brian, >>>> >>>> thanks for your detailed review. >>>> >>>> I have updated the security consideration section based on your >>>> comments. I have added text to describe security threats in more >>>> detail, discuss what the assumptions are (trust model), provide >>>> security requirements, and updated the part that talks about the >>>> specific solution mechanisms. >>> >>> Thanks! Your re-written security considerations section is very much >>> improved. I do have a couple of comments/questions inline below. >>> >>>> >>>> I also added a sentence about the authorization aspect you >>>> mentioned. There is nothing special about RMD that would require >>>> additional description beyond what is covered in the QoS NSLP and >>>> the solutions we had worked on in the context of the Diameter QoS >>>> application. The authorizatoin aspect largely happens before RMD >>>> signaling is actually triggered. >>>> >>>> My proposed text can be found below (before Georgios adds it to the >>>> draft itself). >>>> >>>> Ciao >>>> Hannes >>>> >>>> --------------- >>>> >>>> >>>> 5. Security Considerations >>>> >>>> I. INTRODUCTION >>>> >>>> A design goal of the RMD-QOSM protocol is to be "lightweight" in terms >>>> of the number of exchanged signaling message and the amount of state >>>> established at involved signaling nodes (with and without reduced >>>> state operation). A side-effect of this design decision is to >>>> introduce >>>> second-class signaling nodes, namely QNE Interior nodes, that are >>>> restricted >>>> in their ability to perform QoS signaling actions. Only the QNE >>>> Ingress and >>>> the QNE Egress nodes are allowed to initiate certain signaling >>>> messages. >>>> Moreover, RMD focuses on an intra-domain deployment only. >>>> >>>> The above description has the following implications for security: >>>> >>>> 1) QNE Ingress and QNE Egress nodes require more security and fault >>>> protection >>>> than QNE Interior nodes because their uncontrolled behavior has larger >>>> implications for the overall stability of the network. >>>> >>>> 2) The focus on intra-domain QoS signaling simplifies trust >>>> management and >>>> reduces overall complexity. See Section 2 of RFC 4081 for a more >>>> detailed >>>> discussion about the complete set of communication models available >>>> for >>>> end-to-end QoS signaling protocols. >>>> >>>> It is important to highlight that RMD always uses the message exchange >>>> shown in Figure 24 >>>> even if there is no end-to-end signaling session. If the RMD-QOSM is >>>> triggered based on an E2E signaling exchange then the RESERVE message >>>> is created by a node outside the RMD domain and will subsequently >>>> travel further on (e.g., to the data receiver). Such an exchange is >>>> shown in Figure 3. As such, an evaluation of RMD's security >>>> always has to be seen as a combination of the two signaling >>>> sessions, (1) >>>> and (2) of Figure 24. >>>> >>>> QNE QNE QNE QNE >>>> Ingress Interior Interior Egress >>>> NTLP stateful NTLP stateless NTLP stateless NTLP stateful >>>> | | | | >>>> | RESERVE (1) | | | >>>> +--------------------------------------------->| >>>> | RESERVE` (2) | | | >>>> +-------------->| | | >>>> | | RESERVE` | | >>>> | +-------------->| | >>>> | | | RESERVE` | >>>> | | +------------->| >>>> | | | RESPONSE` (2)| >>>> |<---------------------------------------------+ >>>> | | | RESPONSE (1) | >>>> |<---------------------------------------------+ >>>> >>>> Figure 24: RMD Message Exchange. >>>> >>>> Authorizing quality of service reservations is accomplished >>>> using the AAA framework and the functionality is inherited from >>>> the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], >>>> and not described again in this document. As a technical >>>> solution mechanism Diameter QoS application >>>> [I-D.ietf-dime-diameter-qos] may be used. >>> >>> I assume that it is implied that this authorization is done by the >>> Ingress router, as opposed to each Interior node in the path. It >>> would be helpful to say this. >> >> That's true. I extended the paragraph to: >> >> " >> Authorizing quality of service reservations is accomplished >> using the AAA framework and the functionality is inherited from >> the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], >> and not described again in this document. As a technical >> solution mechanism Diameter QoS application >> [I-D.ietf-dime-diameter-qos] may be used. The end-to-end >> reservation request arriving at the ingress node will >> trigger the authorization procedure with the backend AAA >> infrastructure. The end-to-end reservation is typically >> triggered by a human interaction with a software application, >> such as a voice-over-IP client when making a call. When >> authorization is successful then no further user initiated >> QoS authorization check is expected to be performed within >> the RMD domain for the intra-domain reservation. >> " >> >>> >>>> >>>> >>>> II. SECURITY THREATS >>>> >>>> In the RMD-QOSM, the ingress node constructs both end-to- >>>> end and intra-domain signaling messages based on the >>>> end-to-end message initiated by the sender end node. The >>>> Interior nodes within the RMD network ignore the end-to-end >>>> signaling message, but process, modify, and forward the intra-domain >>>> signaling messages towards the egress node. In the >>>> meantime, resource reservation states are installed, modified >>>> or deleted at each interior node along the data path according >>>> to the content of each intra-domain signaling message. The >>>> edge nodes of an RMD network are critical components >>>> that require strong security protection. Therefore, they act >>>> as security gateways for incoming and outgoing signaling >>>> messages. Moreover, a certain degree of trust has to be placed >>>> into Interior nodes within the RMD-QOSM network, such that >>>> these nodes can perform signaling message processing and >>>> take the necessary actions. >>>> >>>> With the RMD-QOSM we assume that the >>>> ingress and the egress nodes are not controlled by an adversary >>>> and the communication between the ingress and the egress >>>> nodes is secured using standard GIST security mechanisms >>> >>> Is there a reference for these security mechanisms? >>> >> I added a reference to the security consideration section of GIST >> (Section 6 of [I-D.ietf-nsis-ntlp]).. >> >>>> and experiences integrity, replay and confidentiality protection. >>>> Note that this only affects messages directly addressed by >>>> these two nodes and not any other message that needs to >>>> be processed by intermediaries. The SESSION ID object >>>> of the end-to-end communication is visible, via GIST, to the >>>> Interior nodes. >>>> In order to define the security threats that are associated >>>> with the RMD-QOSM we consider that an adversary that may be located >>>> inside the RMD domain and could >>>> drop, delay, duplicate, inject, or modify signaling packets. >>>> Depending on location of adversary, we speak about an on-path >>>> adversary or an off-path adversary, see also RFC 4081 [RFC4081]. >>>> >>>> >>>> II-A. On-path Adversary >>>> >>>> The on-path adversary is a node, which supports RMD-QOSM >>>> and is able to observe RMD-QOSM signaling message >>>> exchanges. >>>> >>>> 1) Dropping signaling messages >>>> >>>> An adversary could drop any signaling messages after >>>> receiving them. This will cause a failure of reservation >>>> request for new sessions or deletion of resource units >>>> (bandwidth) for on-going sessions due to states timeout. >>>> It may trigger the ingress node to retransmit the >>>> lost signaling messages. In this scenario the adversary >>>> drops selected signaling messages, for example intra-domain reserve >>>> messages. In the RMD-QOSM, the retransmission >>>> mechanism can be provided at the ingress node >>>> to make sure that signaling messages can reach the >>>> egress node. However, the retransmissions triggered by >>>> the adversary dropping messages may cause certain >>>> problems. Therefore, it is recommended to disable the use >>>> of retransmissions in the RMD-QOSM aware network. >>>> >>>> 2) Delaying Signaling Messages >>>> >>>> Any signaling message could be delayed by an adversary. >>>> For example, if RESERVE` messages >>>> are delayed over the duration of the refresh period then the >>>> resource units >>>> (bandwidth) reserved along the nodes for corresponding >>>> sessions will be removed. In this situation, the ingress >>>> node does not receive the RESPONSE within a certain >>>> period, and considers that the signaling message is >>>> failed, which may cause a retransmission of the ’failed’ >>>> message. The egress node may distinguish between the >>>> two messages, i.e., the delayed message and the retransmitted >>>> message, and it could take a proper response. >>>> However, interior nodes suffer from this retransmission >>>> and they may reserve twice the resource units (bandwidth) >>>> requested by the ingress node. >>> >>> Can this threat be generalized from "twice" to "N times", if the >>> message is retransmitted N times? >>> If so, it seems like a serious threat. Can the mitigation for >>> Replayed Signaling Messages (i.e., storing values) be used here. >>> Actually, from the description a retransmitted signaling message >>> seems indistinguishable from a replayed signaling message. >>> >> For interior nodes it is not possible to distinguish replays. The >> only entities that detect the replays are edge devices. So, my >> proposal is to let the egress detect and to alert about the potential >> problem. >> >> >>>> >>>> 3) Replaying Signaling Messages >>>> >>>> An adversary may want to replay signaling messages. >>>> It first stores the >>>> received messages and decides when to replay these >>>> message and at what rate (packets/per seconds). >>>> When the RESERVE` message >>>> carried a RII object, the egress will reply with a >>>> RESPONSE` message towards the ingress node. The ingress >>>> node can then detect replays by comparing the value of >>>> RII in the RESPONSE` messages with the stored value. >>>> >>>> 4) Injecting Signaling Messages >>>> >>>> Similar to the replay-attack scenario, the adversary may >>>> store a part of the information carried by signaling >>>> messages, for example, the RSN object. When the >>>> adversary injects signaling messages, it puts the stored >>>> information together with its own generated parameters >>>> (Bandwidth, RII, etc.) into the injected messages and >>>> then sends them out. Interior nodes will process these >>>> messages by default, reserve the requested resource units >>>> (bandwidth) and pass them to downstream nodes. It >>>> may happen that the resource units (bandwidth) on the >>>> Interior nodes are exhausted if these injected messages >>>> consume much bandwidth. >>>> >>>> 5) Modifying Signaling Messages >>>> >>>> On-path adversaries are capable of modifying any part >>>> of the signaling message. For example, the adversary >>>> can modify the , and parameters >>>> of the RMD-QSPEC messages. The egress node >>>> will then use the SESSION ID and subsequently the >>>> BOUND SESSION ID objects to refer to that flow >>>> to be terminated or set to lower priority. It is also >>>> possible for the adversary to modify the >>>> and/or parameter, which could cause >>>> a modification of an amount of the requested resource >>>> units (bandwidth) changes. >>> >>> Don't interior nodes protect RESERVE` and RESPONSE` messages using >>> hop-by-hop security, or is that just RESERVE and RESPONSE messages? >>> It seems like that would be a simple measure to mitigate threats >>> (4) and (5). >>> >> RESERVE and RESPONSE messages use hop-by-hop security. Keep in mind >> that for these two messages the "hop" are ingress and egress; for the >> interior nodes these messages cannot be modified. >> >> Using hop-by-hop security for RESERVE` and RESPONSE` messages does >> not help since the adversary model assumes that one of the interior >> nodes is acting maliciously. >> >> Does this make sense to you? >> >>>> II-B. Off-path Adversary >>>> >>>> In this case the adversary is not located on-path and it >>>> does not participate in the exchange of RMD-QOSM signaling >>>> messages, and therefore is unable to eavesdrop signaling >>>> messages. Hence, the adversary does not know valid RIIs, >>>> RSNs, SESSION IDs. Hence, the adversary has to generate >>>> new parameters and constructs new signaling messages. Since >>>> Interior nodes operate in reduced state mode, >>>> injected signaling messages are treated as new once, which >>>> causes Interior nodes to allocate additional reservation state. >>>> >>>> >>>> III. SECURITY REQUIREMENTS >>>> >>>> The following security requirements are set as goals for the >>>> intra-domain communication, namely: >>>> >>>> * Nodes, which are never supposed to participate in the NSIS signaling >>>> exchange, must not interfere with QNE Interior nodes. Off-path >>>> nodes (off-path with regard to the path taken by a particular >>>> signaling message exchange) must not be able to interfere with >>>> other on-path signaling nodes. >>>> >>>> * The actions allowed by a QNE Interior node should be minimal (i.e., >>>> only those specified by the RMD-QOSM). For example, only the QNE >>>> Ingress and the QNE Egress nodes are allowed to initiate certain >>>> signaling messages. QNE Interior nodes are, for example, allowed to >>>> modify certain signaling message payloads. >>>> >>>> Note that the term `interfere` refers to all sorts of security >>>> threats, such as denial of service, spoofing, replay, signaling >>>> message injection, etc. >>>> >>>> III. SECURITY MECHANISMS >>> >>> Nit: should be "IV." >> Yup. >> >>> >>>> >>>> An important security mechanism that was >>>> built into RMD-QOSM was the ability to tie the end-to-end >>>> RESERVE and the RESERVE` messages >>>> together using the BOUND SESSION ID and to allow the >>>> ingress node to match the RESERVE` >>>> with the RESPONSE` by using the >>>> RII. These mechanisms enable the edge nodes to detect unexpected >>>> signaling messages. >>>> >>>> We assume that the RESERVE/RESPONSE is sent with hop-by-hop >>>> channel security provided by GIST and protected between the QNE >>>> Ingress and the QNE Egress. >>> >>> If the RESERVE/RESPONSE messages are protected hop-by-hop, why can't >>> RESERVE`/RESPONSE` messages? Or does hop-by-hop mean that only the >>> ingress and egress devices are "hops" and share keys? >>> >> See response above. >> >> Ciao >> Hannes >> >>> Thanks, >>> Brian >>> >>>> GIST security mechanisms MUST be used >>>> to offer authentication, >>>> integrity, and replay protection. Furthermore, encryption MUST be used >>>> to >>>> prevent an adversary located along the path of the RESERVE >>>> message to learn information about the session that can later be used >>>> to inject a RESERVE` message. >>>> >>>> The following messages need to be mapped to >>>> each other to make sure that the occurrence of one message is not >>>> without the other one: >>>> >>>> a) the RESERVE and the RESERVE` relate to each other at the QNE >>>> Egress and >>>> >>>> b) the RESPONSE and the RESERVE relate to each other at the QNE >>>> Ingress and >>>> >>>> c) the RESERVE` and the RESPONSE` relate to each other. The RII is >>>> carried in the RESERVE` message and the RESPONSE` message that is >>>> generated by the QNE Egress node contains the same RII as the >>>> RESERVE`. The RII can be used by the QNE Ingress to match the >>>> RESERVE` with the RESPONSE`. The QNE Egress is able to determine >>>> whether the RESERVE` was created by the QNE Ingress node since the >>>> intra-domain session, which sent the RESERVE`, is bound to an end-to- >>>> end session via the BOUND_SESSION_ID value included in the intra- >>>> domain QoS-NSLP operational state maintained at the QNE Egress. >>>> >>>> The RESERVE and the RESERVE` message are tied together using the >>>> BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end >>>> QoS-NSLP operational states maintained at the QNE edges, see Section >>>> 4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a >>>> corresponding RESERVE. The SESSION_ID can fulfill this purpose quite >>>> well if the aim is to provide protection against off-path adversaries >>>> that do not see the SESSION_ID carried in the RESERVE and the >>>> RESERVE` messages. >>>> >>>> If, however, the path changes (due to re-routing or due to mobility) >>>> then an adversary could inject RESERVE` messages (with a previously >>>> seen SESSION_ID) and could potentially cause harm. >>>> >>>> An off-path adversary can, of course, create RESERVE` messages that >>>> cause intermediate nodes to create some state (and cause other >>>> actions) but the message would finally hit the QNE Egress node. The >>>> QNE Egress node would then be able to determine that there is >>>> something going wrong and generate an error message. >>>> >>>> The severe congestion handling can be triggered by intermediate nodes >>>> (unlike other messages). In many cases, however, intermediate nodes >>>> experiencing congestion use refresh messages modify the and >>>> parameters of the message. These messages are still >>>> initiated by the QNE Ingress node and carry the SESSION_ID. The QNE >>>> Egress node will use the SESSION_ID and subsequently the >>>> BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP operational >>>> state, to refer to a flow that might be terminated. The >>>> aspect of intermediate nodes initiating messages for severe >>>> congestion handling is for further study. >>>> >>>> QNE Ingress QNE Interior QNE Interior QNE Egress >>>> NTLP stateful NTLP stateless NTLP stateless NTLP stateful >>>> | | | | >>>> | REFRESH RESERVE` | | >>>> +-------------->| REFRESH RESERVE` | >>>> | (+RII) +-------------->| REFRESH RESERVE` >>>> | | (+RII) +------------->| >>>> | | | (+RII) | >>>> | | | | >>>> | | | REFRESH | >>>> | | | RESPONSE`| >>>> |<---------------------------------------------+ >>>> | | | (+RII) | >>>> >>>> Figure 25: RMD REFRESH message exchange >>>> >>>> During the refresh procedure a RESERVE` creates a RESPONSE`, see >>>> Figure 25. The RII is carried in the RESERVE` message and the >>>> RESPONSE` message that is generated by the QNE Egress node contains >>>> the same RII as the RESERVE`. >>>> >>>> The RII can be used by the QNE Ingress to match the RESERVE` with the >>>> RESPONSE`. >>>> >>>> A further aspect is marking of data traffic. Data packets can be >>>> modified by an intermediary without any relationship to a signaling >>>> session (and a SESSION_ID). The problem appears if an off-path >>>> adversary injects spoofed data packets. >>>> >>>> >>>> The adversary thereby needs to spoof data packets that relate to the >>>> flow identifier of an existing end-to-end reservation that SHOULD be >>>> terminated. Therefore the question arises how an off-path adversary >>>> SHOULD create a data packet that matches an existing flow identifier >>>> (if a 5-tuple is used). Hence, this might not turn out to be simple >>>> for an adversary unless we assume the previously mentioned >>>> mobility/re-routing case where the path through the network changes >>>> and the set of nodes that are along a path changes over time. >>>> >>>> >>>> >>>> >>>> Brian Weis 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. >>>>> >>>>> This document describes an NSIS QoS Model for networks that use >>>>> the Resource Management in Diffserv (RMD) concept. It describes >>>>> RMD-QOSM, which are new payloads sent using the GISP signaling >>>>> mechanism, where the new payloads request or reserve resources. A >>>>> number of data flows are discussed, depending on whether nodes >>>>> within a network boundary participate in the protocol or not. >>>>> >>>>> The Security Considerations section covers the following topics: >>>>> - Byzantine adversaries (i.e., participants taken over by an >>>>> adversary) are a general problem, but this section intends to >>>>> discuss additional threats as a result of the new protocol. There >>>>> is an extensive discussion of on-path and off-path adversaries, >>>>> which seems to intend to be addressing Byzantine adversaries. >>>>> - RMD-QOSM is claimed to be lightweight, with different routers >>>>> allowed certain operations dependant on the role a router plays in >>>>> the system. E.g., only Ingress/Egress nodes are allowed to >>>>> initiate certain signaling messages. >>>>> - RMD-QOSM "relies on the security support that is provided by the >>>>> bounded end-to-end session, which is running between the >>>>> boundaries of the RMD domain", but doesn't mandate that security >>>>> support. >>>>> >>>>> The existing text is helpful, but not sufficient. The following >>>>> points are suggestions to improve this section. >>>>> >>>>> 1. The statement at the beginning of Security Considerations >>>>> discusses adversaries taking over a router, but the new threats >>>>> are not very clear. Are the authors considering that security >>>>> associations are revealed, that reservation data routed to a >>>>> particular router can be changed or forged, or something else? >>>>> >>>>> 2. The trust model used by RMD-QOSM is hinted at in the discussion >>>>> of on-path and off-path adversaries, but a discussion of exactly >>>>> what devices are trusted and what they're trusted to do would be >>>>> helpful. For example, is every interior router in the network is >>>>> trusted to handle any particular RESERVE or RESERVE` message? If >>>>> not, then how are the paths setup so that only authorized routers >>>>> will see a particular message? On the other hand, if routing is >>>>> used to route the messages then it would seem that any router must >>>>> be authorized to handle messages happened to be routed to them -- >>>>> but then it isn't clear that there can be a difference between an >>>>> "on-path" and "off-path" adversary. >>>>> >>>>> 3. Another dimension of trust model is the fact that >>>>> ingress/egress routers seem to trust each other more than they >>>>> trust interior nodes. This seems evidenced by the fact that >>>>> RESERVE messages (Figure 24) don't seem to be intended to be >>>>> modified by the interior routers. In the case of probes, I would >>>>> expect that this would be especially important, but probes do not >>>>> seem to be specifically discussed in this section. >>>>> >>>>> 4. There don't seem to be any actual security requirements or >>>>> recommendations made on GIST messaging. As such, it isn't clear >>>>> that attackers that have not taken over a participant (i.e., a man >>>>> in the middle) are in any way foiled. I would expect to see more >>>>> MUSTs and SHOULDs in this section regarding message security. >>>>> There are statements in the I-D such as "In the situation a >>>>> security association exists" and "If we assume that the >>>>> RESERVE/RESPONSE is sent with hop-by-hop channel security". There >>>>> should be some description of the threats to the messaging by a >>>>> non-participant, and stating what available mechanisms MUST or >>>>> SHOULD be used. >>>>> >>>>> 5. Since roles seem to be an important part of the security >>>>> considerations, it would be helpful to see discussion of the >>>>> different threats & requirements on the ingress/egress routers and >>>>> the internal routers in their different roles. >>>>> >>>>> 6. An important service of RMD-QOSM is admission control, but >>>>> there doesn't seem to be any discussion of how the ingress routers >>>>> determine whether or not reservation requests given to them are >>>>> valid. I would have thought that is of particular importance, but >>>>> if it's considered out of scope this section might mention that fact. >>>> >>>>> >>>>> Hope that helps, >>>>> Brian >>>>> _______________________________________________ >>>>> secdir mailing list >>>>> secdir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/secdir >>>> >>> >>> >> > > From bew@cisco.com Wed May 5 15:19:31 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFEEF3A6CE6; Wed, 5 May 2010 15:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm-iyq96t66K; Wed, 5 May 2010 15:19:27 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7D6243A6D26; Wed, 5 May 2010 15:19:26 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALKL4UurR7Hu/2dsb2JhbACdU3GkbplggnWCHgSDPg X-IronPort-AV: E=Sophos;i="4.52,336,1270425600"; d="scan'208";a="193113202" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 05 May 2010 22:19:13 +0000 Received: from dhcp-128-107-163-73.cisco.com (dhcp-128-107-163-73.cisco.com [128.107.163.73]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o45MJDei021060; Wed, 5 May 2010 22:19:13 GMT Message-Id: From: Brian Weis To: Hannes Tschofenig In-Reply-To: <4BE1EAE3.6030304@gmx.net> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 5 May 2010 15:19:11 -0700 References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> <4BDC0A38.20507@gmx.net> <4BE1B678.8020805@gmx.net> <4BE1EAE3.6030304@gmx.net> X-Mailer: Apple Mail (2.936) Cc: nsis-chairs@tools.ietf.org, draft-ietf-nsis-rmd@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 22:19:31 -0000 Hi Hannes, You new wording looks good to me. I have no further comments. Thanks, Brian On May 5, 2010, at 3:02 PM, Hannes Tschofenig wrote: > Hi Brian, > > > Brian Weis wrote: >> Hi Hannes, >> >> The expanded authorization paragraph is very clear to me, thanks. >> >> Regarding protection of the RESERVE` and RESPONSE` hop-by-hop =20 >> security: >> >>>> Don't interior nodes protect RESERVE` and RESPONSE` messages =20 >>>> using hop-by-hop security, or is that just RESERVE and RESPONSE =20= >>>> messages? It seems like that would be a simple measure to =20 >>>> mitigate threats (4) and (5). >>>> >>> RESERVE and RESPONSE messages use hop-by-hop security. Keep in =20 >>> mind that for these two messages the "hop" are ingress and egress; =20= >>> for the interior nodes these messages cannot be modified. >> >> Thanks for the clarification of what constitutes a "hop". So if I =20 >> understand correctly, only Ingress and Egress routers share a =20 >> security association for protecting RESERVE and RESPONSE messages. > Yes. > >> >>> Using hop-by-hop security for RESERVE` and RESPONSE` messages does =20= >>> not help since the adversary model assumes that one of the =20 >>> interior nodes is acting maliciously. >>> >>> Does this make sense to you? >> >> >> My point was that transport security of RESERVE` and RESPONSE` =20 >> messages between Interior nodes would also be helpful to protect =20 >> each Interior node from on-path attackers between themselves. I =20 >> assume they may have adversaries between them. > Well. There is actually no other entity between the participating =20 > interior nodes. In RMD all the nodes in the domain have to =20 > participate. > >> >> But I think I understand now that the Security Considerations =20 >> section is written assuming that only Ingress and Egress devices =20 >> participate in any kind of security association. > > Yes. > >> You're not trusting the Interior nodes at all, so they themselves =20 >> have no security considerations. > Normally, with a QoS signaling protocol you have to essentially =20 > trust every node that understands the protocol. In RMD I thought =20 > that it would be interesting to exploit the fact that you can do =20 > better than that. > >> Could you please clarify the following points in the INTRODUCTION, =20= >> which would make that clearer? >> - What is a "hop" with respect to security associations >> - The security of RMD-QOSM does not depend on interior nodes. (It =20 >> does say "The focus on intra-domain QoS signaling simplifies trust =20= >> management and reduces overall complexity." but that's doesn't =20 >> really go far enough.) >> - Because the security of RMD-QOSM does not depend on interior =20 >> nodes, protection of RESERVE` and RESPONSE` messages is not =20 >> specified. >> > Sure. Makes sense. Here is my proposal: > > I. INTRODUCTION > > A design goal of the RMD-QOSM protocol is to be "lightweight" in =20 > terms > of the number of exchanged signaling message and the amount of state > established at involved signaling nodes (with and without reduced > state operation). A side-effect of this design decision is to =20 > introduce > second-class signaling nodes, namely QNE Interior nodes, that are =20 > restricted > in their ability to perform QoS signaling actions. Only the QNE =20 > Ingress and > the QNE Egress nodes are allowed to initiate certain signaling =20 > messages. > Moreover, RMD focuses on an intra-domain deployment only. > The above description has the following implications for security: > > 1) QNE Ingress and QNE Egress nodes require more security and fault =20= > protection > than QNE Interior nodes because their uncontrolled behavior has =20= > larger > implications for the overall stability of the network. QNE =20 > Ingress and > QNE Egress nodes share a security association and utlize GIST =20 > security > for protection of their signaling messages. Intra-domain signaling > messages used for RMD signaling do not use GIST security and =20 > therefore > they do not store security associations. > > 2) The focus on intra-domain QoS signaling simplifies trust =20 > management and > reduces overall complexity. See Section 2 of RFC 4081 for a more =20= > detailed > discussion about the complete set of communication models =20 > available for > end-to-end QoS signaling protocols. The security of RMD-QOSM =20 > does not > depend on interior nodes and hence the cryptographic protection of > intra-domain messages via GIST is not utilized. > > It is important to highlight that RMD always uses the message =20 > exchange > shown in Figure 24 > even if there is no end-to-end signaling session. If the RMD-QOSM is > triggered based on an E2E signaling exchange then the RESERVE message > is created by a node outside the RMD domain and will subsequently > travel further on (e.g., to the data receiver). Such an exchange is > shown in Figure 3. As such, an evaluation of RMD's security > always has to be seen as a combination of the two signaling =20 > sessions, (1) > and (2) of Figure 24. Note that for the E2E message, such as > the RESERVE and the RESPONSE message, a single "hop" refers to > the communication between the QNE Ingress and the QNE Egress > since QNE Interior nodes do not participate in the exchange. > > Ciao > Hannes > >> Thanks, >> Brian >> >> On May 5, 2010, at 11:18 AM, Hannes Tschofenig wrote: >> >>> Hi Brian, >>> >>> thanks for the quick response. >>> >>> Brian Weis wrote: >>>> Hi Hannes, >>>> >>>> On May 1, 2010, at 4:02 AM, Hannes Tschofenig wrote: >>>> >>>>> Hey Brian, >>>>> >>>>> thanks for your detailed review. >>>>> >>>>> I have updated the security consideration section based on your =20= >>>>> comments. I have added text to describe security threats in more =20= >>>>> detail, discuss what the assumptions are (trust model), provide =20= >>>>> security requirements, and updated the part that talks about the =20= >>>>> specific solution mechanisms. >>>> >>>> Thanks! Your re-written security considerations section is very =20 >>>> much improved. I do have a couple of comments/questions inline =20 >>>> below. >>>> >>>>> >>>>> I also added a sentence about the authorization aspect you =20 >>>>> mentioned. There is nothing special about RMD that would require =20= >>>>> additional description beyond what is covered in the QoS NSLP =20 >>>>> and the solutions we had worked on in the context of the =20 >>>>> Diameter QoS application. The authorizatoin aspect largely =20 >>>>> happens before RMD signaling is actually triggered. >>>>> >>>>> My proposed text can be found below (before Georgios adds it to =20= >>>>> the draft itself). >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> --------------- >>>>> >>>>> >>>>> 5. Security Considerations >>>>> >>>>> I. INTRODUCTION >>>>> >>>>> A design goal of the RMD-QOSM protocol is to be "lightweight" in =20= >>>>> terms >>>>> of the number of exchanged signaling message and the amount of =20 >>>>> state >>>>> established at involved signaling nodes (with and without reduced >>>>> state operation). A side-effect of this design decision is to =20 >>>>> introduce >>>>> second-class signaling nodes, namely QNE Interior nodes, that =20 >>>>> are restricted >>>>> in their ability to perform QoS signaling actions. Only the QNE =20= >>>>> Ingress and >>>>> the QNE Egress nodes are allowed to initiate certain signaling =20 >>>>> messages. >>>>> Moreover, RMD focuses on an intra-domain deployment only. >>>>> >>>>> The above description has the following implications for security: >>>>> >>>>> 1) QNE Ingress and QNE Egress nodes require more security and =20 >>>>> fault protection >>>>> than QNE Interior nodes because their uncontrolled behavior has =20= >>>>> larger >>>>> implications for the overall stability of the network. >>>>> >>>>> 2) The focus on intra-domain QoS signaling simplifies trust =20 >>>>> management and >>>>> reduces overall complexity. See Section 2 of RFC 4081 for a more =20= >>>>> detailed >>>>> discussion about the complete set of communication models =20 >>>>> available for >>>>> end-to-end QoS signaling protocols. >>>>> >>>>> It is important to highlight that RMD always uses the message =20 >>>>> exchange >>>>> shown in Figure 24 >>>>> even if there is no end-to-end signaling session. If the RMD-=20 >>>>> QOSM is >>>>> triggered based on an E2E signaling exchange then the RESERVE =20 >>>>> message >>>>> is created by a node outside the RMD domain and will subsequently >>>>> travel further on (e.g., to the data receiver). Such an exchange =20= >>>>> is >>>>> shown in Figure 3. As such, an evaluation of RMD's security >>>>> always has to be seen as a combination of the two signaling =20 >>>>> sessions, (1) >>>>> and (2) of Figure 24. >>>>> >>>>> QNE QNE QNE QNE >>>>> Ingress Interior Interior Egress >>>>> NTLP stateful NTLP stateless NTLP stateless NTLP stateful >>>>> | | | | >>>>> | RESERVE (1) | | | >>>>> +--------------------------------------------->| >>>>> | RESERVE` (2) | | | >>>>> +-------------->| | | >>>>> | | RESERVE` | | >>>>> | +-------------->| | >>>>> | | | RESERVE` | >>>>> | | +------------->| >>>>> | | | RESPONSE` (2)| >>>>> |<---------------------------------------------+ >>>>> | | | RESPONSE (1) | >>>>> |<---------------------------------------------+ >>>>> >>>>> Figure 24: RMD Message Exchange. >>>>> >>>>> Authorizing quality of service reservations is accomplished >>>>> using the AAA framework and the functionality is inherited from >>>>> the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], >>>>> and not described again in this document. As a technical >>>>> solution mechanism Diameter QoS application >>>>> [I-D.ietf-dime-diameter-qos] may be used. >>>> >>>> I assume that it is implied that this authorization is done by =20 >>>> the Ingress router, as opposed to each Interior node in the path. =20= >>>> It would be helpful to say this. >>> >>> That's true. I extended the paragraph to: >>> >>> " >>> Authorizing quality of service reservations is accomplished >>> using the AAA framework and the functionality is inherited from >>> the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], >>> and not described again in this document. As a technical >>> solution mechanism Diameter QoS application >>> [I-D.ietf-dime-diameter-qos] may be used. The end-to-end >>> reservation request arriving at the ingress node will >>> trigger the authorization procedure with the backend AAA >>> infrastructure. The end-to-end reservation is typically >>> triggered by a human interaction with a software application, >>> such as a voice-over-IP client when making a call. When >>> authorization is successful then no further user initiated >>> QoS authorization check is expected to be performed within >>> the RMD domain for the intra-domain reservation. >>> " >>> >>>> >>>>> >>>>> >>>>> II. SECURITY THREATS >>>>> >>>>> In the RMD-QOSM, the ingress node constructs both end-to- >>>>> end and intra-domain signaling messages based on the >>>>> end-to-end message initiated by the sender end node. The >>>>> Interior nodes within the RMD network ignore the end-to-end >>>>> signaling message, but process, modify, and forward the intra-=20 >>>>> domain >>>>> signaling messages towards the egress node. In the >>>>> meantime, resource reservation states are installed, modified >>>>> or deleted at each interior node along the data path according >>>>> to the content of each intra-domain signaling message. The >>>>> edge nodes of an RMD network are critical components >>>>> that require strong security protection. Therefore, they act >>>>> as security gateways for incoming and outgoing signaling >>>>> messages. Moreover, a certain degree of trust has to be placed >>>>> into Interior nodes within the RMD-QOSM network, such that >>>>> these nodes can perform signaling message processing and >>>>> take the necessary actions. >>>>> >>>>> With the RMD-QOSM we assume that the >>>>> ingress and the egress nodes are not controlled by an adversary >>>>> and the communication between the ingress and the egress >>>>> nodes is secured using standard GIST security mechanisms >>>> >>>> Is there a reference for these security mechanisms? >>>> >>> I added a reference to the security consideration section of GIST =20= >>> (Section 6 of [I-D.ietf-nsis-ntlp]).. >>> >>>>> and experiences integrity, replay and confidentiality protection. >>>>> Note that this only affects messages directly addressed by >>>>> these two nodes and not any other message that needs to >>>>> be processed by intermediaries. The SESSION ID object >>>>> of the end-to-end communication is visible, via GIST, to the >>>>> Interior nodes. >>>>> In order to define the security threats that are associated >>>>> with the RMD-QOSM we consider that an adversary that may be =20 >>>>> located >>>>> inside the RMD domain and could >>>>> drop, delay, duplicate, inject, or modify signaling packets. >>>>> Depending on location of adversary, we speak about an on-path >>>>> adversary or an off-path adversary, see also RFC 4081 [RFC4081]. >>>>> >>>>> >>>>> II-A. On-path Adversary >>>>> >>>>> The on-path adversary is a node, which supports RMD-QOSM >>>>> and is able to observe RMD-QOSM signaling message >>>>> exchanges. >>>>> >>>>> 1) Dropping signaling messages >>>>> >>>>> An adversary could drop any signaling messages after >>>>> receiving them. This will cause a failure of reservation >>>>> request for new sessions or deletion of resource units >>>>> (bandwidth) for on-going sessions due to states timeout. >>>>> It may trigger the ingress node to retransmit the >>>>> lost signaling messages. In this scenario the adversary >>>>> drops selected signaling messages, for example intra-domain =20 >>>>> reserve >>>>> messages. In the RMD-QOSM, the retransmission >>>>> mechanism can be provided at the ingress node >>>>> to make sure that signaling messages can reach the >>>>> egress node. However, the retransmissions triggered by >>>>> the adversary dropping messages may cause certain >>>>> problems. Therefore, it is recommended to disable the use >>>>> of retransmissions in the RMD-QOSM aware network. >>>>> >>>>> 2) Delaying Signaling Messages >>>>> >>>>> Any signaling message could be delayed by an adversary. >>>>> For example, if RESERVE` messages >>>>> are delayed over the duration of the refresh period then the =20 >>>>> resource units >>>>> (bandwidth) reserved along the nodes for corresponding >>>>> sessions will be removed. In this situation, the ingress >>>>> node does not receive the RESPONSE within a certain >>>>> period, and considers that the signaling message is >>>>> failed, which may cause a retransmission of the =92failed=92 >>>>> message. The egress node may distinguish between the >>>>> two messages, i.e., the delayed message and the retransmitted >>>>> message, and it could take a proper response. >>>>> However, interior nodes suffer from this retransmission >>>>> and they may reserve twice the resource units (bandwidth) >>>>> requested by the ingress node. >>>> >>>> Can this threat be generalized from "twice" to "N times", if the =20= >>>> message is retransmitted N times? >>>> If so, it seems like a serious threat. Can the mitigation for =20 >>>> Replayed Signaling Messages (i.e., storing values) be used here. =20= >>>> Actually, from the description a retransmitted signaling message =20= >>>> seems indistinguishable from a replayed signaling message. >>>> >>> For interior nodes it is not possible to distinguish replays. The =20= >>> only entities that detect the replays are edge devices. So, my =20 >>> proposal is to let the egress detect and to alert about the =20 >>> potential problem. >>> >>> >>>>> >>>>> 3) Replaying Signaling Messages >>>>> >>>>> An adversary may want to replay signaling messages. >>>>> It first stores the >>>>> received messages and decides when to replay these >>>>> message and at what rate (packets/per seconds). >>>>> When the RESERVE` message >>>>> carried a RII object, the egress will reply with a >>>>> RESPONSE` message towards the ingress node. The ingress >>>>> node can then detect replays by comparing the value of >>>>> RII in the RESPONSE` messages with the stored value. >>>>> >>>>> 4) Injecting Signaling Messages >>>>> >>>>> Similar to the replay-attack scenario, the adversary may >>>>> store a part of the information carried by signaling >>>>> messages, for example, the RSN object. When the >>>>> adversary injects signaling messages, it puts the stored >>>>> information together with its own generated parameters >>>>> (Bandwidth, RII, etc.) into the injected messages and >>>>> then sends them out. Interior nodes will process these >>>>> messages by default, reserve the requested resource units >>>>> (bandwidth) and pass them to downstream nodes. It >>>>> may happen that the resource units (bandwidth) on the >>>>> Interior nodes are exhausted if these injected messages >>>>> consume much bandwidth. >>>>> >>>>> 5) Modifying Signaling Messages >>>>> >>>>> On-path adversaries are capable of modifying any part >>>>> of the signaling message. For example, the adversary >>>>> can modify the , and parameters >>>>> of the RMD-QSPEC messages. The egress node >>>>> will then use the SESSION ID and subsequently the >>>>> BOUND SESSION ID objects to refer to that flow >>>>> to be terminated or set to lower priority. It is also >>>>> possible for the adversary to modify the >>>>> and/or parameter, which could cause >>>>> a modification of an amount of the requested resource >>>>> units (bandwidth) changes. >>>> >>>> Don't interior nodes protect RESERVE` and RESPONSE` messages =20 >>>> using hop-by-hop security, or is that just RESERVE and RESPONSE =20= >>>> messages? It seems like that would be a simple measure to =20 >>>> mitigate threats (4) and (5). >>>> >>> RESERVE and RESPONSE messages use hop-by-hop security. Keep in =20 >>> mind that for these two messages the "hop" are ingress and egress; =20= >>> for the interior nodes these messages cannot be modified. >>> >>> Using hop-by-hop security for RESERVE` and RESPONSE` messages does =20= >>> not help since the adversary model assumes that one of the =20 >>> interior nodes is acting maliciously. >>> >>> Does this make sense to you? >>> >>>>> II-B. Off-path Adversary >>>>> >>>>> In this case the adversary is not located on-path and it >>>>> does not participate in the exchange of RMD-QOSM signaling >>>>> messages, and therefore is unable to eavesdrop signaling >>>>> messages. Hence, the adversary does not know valid RIIs, >>>>> RSNs, SESSION IDs. Hence, the adversary has to generate >>>>> new parameters and constructs new signaling messages. Since >>>>> Interior nodes operate in reduced state mode, >>>>> injected signaling messages are treated as new once, which >>>>> causes Interior nodes to allocate additional reservation state. >>>>> >>>>> >>>>> III. SECURITY REQUIREMENTS >>>>> >>>>> The following security requirements are set as goals for the >>>>> intra-domain communication, namely: >>>>> >>>>> * Nodes, which are never supposed to participate in the NSIS =20 >>>>> signaling >>>>> exchange, must not interfere with QNE Interior nodes. Off-path >>>>> nodes (off-path with regard to the path taken by a particular >>>>> signaling message exchange) must not be able to interfere with >>>>> other on-path signaling nodes. >>>>> >>>>> * The actions allowed by a QNE Interior node should be minimal =20 >>>>> (i.e., >>>>> only those specified by the RMD-QOSM). For example, only the QNE >>>>> Ingress and the QNE Egress nodes are allowed to initiate certain >>>>> signaling messages. QNE Interior nodes are, for example, allowed =20= >>>>> to >>>>> modify certain signaling message payloads. >>>>> >>>>> Note that the term `interfere` refers to all sorts of security >>>>> threats, such as denial of service, spoofing, replay, signaling >>>>> message injection, etc. >>>>> >>>>> III. SECURITY MECHANISMS >>>> >>>> Nit: should be "IV." >>> Yup. >>> >>>> >>>>> >>>>> An important security mechanism that was >>>>> built into RMD-QOSM was the ability to tie the end-to-end >>>>> RESERVE and the RESERVE` messages >>>>> together using the BOUND SESSION ID and to allow the >>>>> ingress node to match the RESERVE` >>>>> with the RESPONSE` by using the >>>>> RII. These mechanisms enable the edge nodes to detect unexpected >>>>> signaling messages. >>>>> >>>>> We assume that the RESERVE/RESPONSE is sent with hop-by-hop >>>>> channel security provided by GIST and protected between the QNE >>>>> Ingress and the QNE Egress. >>>> >>>> If the RESERVE/RESPONSE messages are protected hop-by-hop, why =20 >>>> can't RESERVE`/RESPONSE` messages? Or does hop-by-hop mean that =20 >>>> only the ingress and egress devices are "hops" and share keys? >>>> >>> See response above. >>> >>> Ciao >>> Hannes >>> >>>> Thanks, >>>> Brian >>>> >>>>> GIST security mechanisms MUST be used >>>>> to offer authentication, >>>>> integrity, and replay protection. Furthermore, encryption MUST =20 >>>>> be used >>>>> to >>>>> prevent an adversary located along the path of the RESERVE >>>>> message to learn information about the session that can later be =20= >>>>> used >>>>> to inject a RESERVE` message. >>>>> >>>>> The following messages need to be mapped to >>>>> each other to make sure that the occurrence of one message is not >>>>> without the other one: >>>>> >>>>> a) the RESERVE and the RESERVE` relate to each other at the QNE >>>>> Egress and >>>>> >>>>> b) the RESPONSE and the RESERVE relate to each other at the QNE >>>>> Ingress and >>>>> >>>>> c) the RESERVE` and the RESPONSE` relate to each other. The RII is >>>>> carried in the RESERVE` message and the RESPONSE` message that is >>>>> generated by the QNE Egress node contains the same RII as the >>>>> RESERVE`. The RII can be used by the QNE Ingress to match the >>>>> RESERVE` with the RESPONSE`. The QNE Egress is able to determine >>>>> whether the RESERVE` was created by the QNE Ingress node since the >>>>> intra-domain session, which sent the RESERVE`, is bound to an =20 >>>>> end-to- >>>>> end session via the BOUND_SESSION_ID value included in the intra- >>>>> domain QoS-NSLP operational state maintained at the QNE Egress. >>>>> >>>>> The RESERVE and the RESERVE` message are tied together using the >>>>> BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end >>>>> QoS-NSLP operational states maintained at the QNE edges, see =20 >>>>> Section >>>>> 4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a >>>>> corresponding RESERVE. The SESSION_ID can fulfill this purpose =20 >>>>> quite >>>>> well if the aim is to provide protection against off-path =20 >>>>> adversaries >>>>> that do not see the SESSION_ID carried in the RESERVE and the >>>>> RESERVE` messages. >>>>> >>>>> If, however, the path changes (due to re-routing or due to =20 >>>>> mobility) >>>>> then an adversary could inject RESERVE` messages (with a =20 >>>>> previously >>>>> seen SESSION_ID) and could potentially cause harm. >>>>> >>>>> An off-path adversary can, of course, create RESERVE` messages =20 >>>>> that >>>>> cause intermediate nodes to create some state (and cause other >>>>> actions) but the message would finally hit the QNE Egress node. =20= >>>>> The >>>>> QNE Egress node would then be able to determine that there is >>>>> something going wrong and generate an error message. >>>>> >>>>> The severe congestion handling can be triggered by intermediate =20= >>>>> nodes >>>>> (unlike other messages). In many cases, however, intermediate =20 >>>>> nodes >>>>> experiencing congestion use refresh messages modify the and >>>>> parameters of the message. These messages are still >>>>> initiated by the QNE Ingress node and carry the SESSION_ID. The =20= >>>>> QNE >>>>> Egress node will use the SESSION_ID and subsequently the >>>>> BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP =20 >>>>> operational >>>>> state, to refer to a flow that might be terminated. The >>>>> aspect of intermediate nodes initiating messages for severe >>>>> congestion handling is for further study. >>>>> >>>>> QNE Ingress QNE Interior QNE Interior QNE Egress >>>>> NTLP stateful NTLP stateless NTLP stateless NTLP stateful >>>>> | | | | >>>>> | REFRESH RESERVE` | | >>>>> +-------------->| REFRESH RESERVE` | >>>>> | (+RII) +-------------->| REFRESH RESERVE` >>>>> | | (+RII) +------------->| >>>>> | | | (+RII) | >>>>> | | | | >>>>> | | | REFRESH | >>>>> | | | RESPONSE`| >>>>> |<---------------------------------------------+ >>>>> | | | (+RII) | >>>>> >>>>> Figure 25: RMD REFRESH message exchange >>>>> >>>>> During the refresh procedure a RESERVE` creates a RESPONSE`, see >>>>> Figure 25. The RII is carried in the RESERVE` message and the >>>>> RESPONSE` message that is generated by the QNE Egress node =20 >>>>> contains >>>>> the same RII as the RESERVE`. >>>>> >>>>> The RII can be used by the QNE Ingress to match the RESERVE` =20 >>>>> with the >>>>> RESPONSE`. >>>>> >>>>> A further aspect is marking of data traffic. Data packets can be >>>>> modified by an intermediary without any relationship to a =20 >>>>> signaling >>>>> session (and a SESSION_ID). The problem appears if an off-path >>>>> adversary injects spoofed data packets. >>>>> >>>>> >>>>> The adversary thereby needs to spoof data packets that relate to =20= >>>>> the >>>>> flow identifier of an existing end-to-end reservation that =20 >>>>> SHOULD be >>>>> terminated. Therefore the question arises how an off-path =20 >>>>> adversary >>>>> SHOULD create a data packet that matches an existing flow =20 >>>>> identifier >>>>> (if a 5-tuple is used). Hence, this might not turn out to be =20 >>>>> simple >>>>> for an adversary unless we assume the previously mentioned >>>>> mobility/re-routing case where the path through the network =20 >>>>> changes >>>>> and the set of nodes that are along a path changes over time. >>>>> >>>>> >>>>> >>>>> >>>>> Brian Weis wrote: >>>>>> I have reviewed this document as part of the security =20 >>>>>> directorate's ongoing effort to review all IETF documents being =20= >>>>>> processed by the IESG. These comments were written primarily =20 >>>>>> for the benefit of the security area directors. Document =20 >>>>>> editors and WG chairs should treat these comments just like any =20= >>>>>> other last call comments. >>>>>> >>>>>> This document describes an NSIS QoS Model for networks that use =20= >>>>>> the Resource Management in Diffserv (RMD) concept. It describes =20= >>>>>> RMD-QOSM, which are new payloads sent using the GISP signaling =20= >>>>>> mechanism, where the new payloads request or reserve resources. =20= >>>>>> A number of data flows are discussed, depending on whether =20 >>>>>> nodes within a network boundary participate in the protocol or =20= >>>>>> not. >>>>>> >>>>>> The Security Considerations section covers the following topics: >>>>>> - Byzantine adversaries (i.e., participants taken over by an =20 >>>>>> adversary) are a general problem, but this section intends to =20 >>>>>> discuss additional threats as a result of the new protocol. =20 >>>>>> There is an extensive discussion of on-path and off-path =20 >>>>>> adversaries, which seems to intend to be addressing Byzantine =20 >>>>>> adversaries. >>>>>> - RMD-QOSM is claimed to be lightweight, with different routers =20= >>>>>> allowed certain operations dependant on the role a router plays =20= >>>>>> in the system. E.g., only Ingress/Egress nodes are allowed to =20 >>>>>> initiate certain signaling messages. >>>>>> - RMD-QOSM "relies on the security support that is provided by =20= >>>>>> the bounded end-to-end session, which is running between the =20 >>>>>> boundaries of the RMD domain", but doesn't mandate that =20 >>>>>> security support. >>>>>> >>>>>> The existing text is helpful, but not sufficient. The following =20= >>>>>> points are suggestions to improve this section. >>>>>> >>>>>> 1. The statement at the beginning of Security Considerations =20 >>>>>> discusses adversaries taking over a router, but the new threats =20= >>>>>> are not very clear. Are the authors considering that security =20 >>>>>> associations are revealed, that reservation data routed to a =20 >>>>>> particular router can be changed or forged, or something else? >>>>>> >>>>>> 2. The trust model used by RMD-QOSM is hinted at in the =20 >>>>>> discussion of on-path and off-path adversaries, but a =20 >>>>>> discussion of exactly what devices are trusted and what they're =20= >>>>>> trusted to do would be helpful. For example, is every interior =20= >>>>>> router in the network is trusted to handle any particular =20 >>>>>> RESERVE or RESERVE` message? If not, then how are the paths =20 >>>>>> setup so that only authorized routers will see a particular =20 >>>>>> message? On the other hand, if routing is used to route the =20 >>>>>> messages then it would seem that any router must be authorized =20= >>>>>> to handle messages happened to be routed to them -- but then it =20= >>>>>> isn't clear that there can be a difference between an "on-path" =20= >>>>>> and "off-path" adversary. >>>>>> >>>>>> 3. Another dimension of trust model is the fact that ingress/=20 >>>>>> egress routers seem to trust each other more than they trust =20 >>>>>> interior nodes. This seems evidenced by the fact that RESERVE =20 >>>>>> messages (Figure 24) don't seem to be intended to be modified =20 >>>>>> by the interior routers. In the case of probes, I would expect =20= >>>>>> that this would be especially important, but probes do not seem =20= >>>>>> to be specifically discussed in this section. >>>>>> >>>>>> 4. There don't seem to be any actual security requirements or =20 >>>>>> recommendations made on GIST messaging. As such, it isn't clear =20= >>>>>> that attackers that have not taken over a participant (i.e., a =20= >>>>>> man in the middle) are in any way foiled. I would expect to see =20= >>>>>> more MUSTs and SHOULDs in this section regarding message =20 >>>>>> security. There are statements in the I-D such as "In the =20 >>>>>> situation a security association exists" and "If we assume that =20= >>>>>> the RESERVE/RESPONSE is sent with hop-by-hop channel security". =20= >>>>>> There should be some description of the threats to the =20 >>>>>> messaging by a non-participant, and stating what available =20 >>>>>> mechanisms MUST or SHOULD be used. >>>>>> >>>>>> 5. Since roles seem to be an important part of the security =20 >>>>>> considerations, it would be helpful to see discussion of the =20 >>>>>> different threats & requirements on the ingress/egress routers =20= >>>>>> and the internal routers in their different roles. >>>>>> >>>>>> 6. An important service of RMD-QOSM is admission control, but =20 >>>>>> there doesn't seem to be any discussion of how the ingress =20 >>>>>> routers determine whether or not reservation requests given to =20= >>>>>> them are valid. I would have thought that is of particular =20 >>>>>> importance, but if it's considered out of scope this section =20 >>>>>> might mention that fact. >>>>> >>>>>> >>>>>> Hope that helps, >>>>>> Brian >>>>>> _______________________________________________ >>>>>> secdir mailing list >>>>>> secdir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/secdir >>>>> >>>> >>>> >>> >> >> > --=20 Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From turners@ieca.com Wed May 5 15:22:11 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1F53A6CE6 for ; Wed, 5 May 2010 15:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EHyqj13kKT9 for ; Wed, 5 May 2010 15:22:06 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id 2BEE03A6CD2 for ; Wed, 5 May 2010 15:22:05 -0700 (PDT) Received: (qmail 25612 invoked from network); 5 May 2010 22:21:49 -0000 Received: from thunderfish.local (turners@71.191.5.111 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 05 May 2010 15:21:47 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: q0CV9_IVM1m7Lc8L65LcFk8kC6Hk6UmbcgQl0zBqabaFvvB6UUqHjpIWhkf.rwLBJUXy0rLa.9zS2sYCDIzZHMeOasX9Ev_0DVxIMf5h5cxoFv6KzzQ3S010.LbVe74QNF8l4D3AsqWDYtWAgR1MN63Y.0SFl6UldZqMhLmMjhYXP.D3zzDx02luxq5qVQOhA3y2yuKU7txo2JOb5IiSqIA2FkHZcr3vKAKXeWrXepZP1qF_iNUlbYinoZZU5jF3gGeLLpMo5FWTzSTZ.x6kcE6zVeAYRx4MaeuZjC33n1Dqkg9HbiKPcFH5h79Pv.flW3jJO9II0bRaepJs1ihXiYeLhZhISmm0WjU88OXPFIKgRK_OrMypXndu8O.9NuheFTh1NA0.0YQbQLnZLW_tzeEHC_NLTCSa.lX3LsR8dBZJ4hI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BE1EF7A.60802@ieca.com> Date: Wed, 05 May 2010 18:21:46 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: draft-ietf-nsis-rmd@tools.ietf.org, iesg@ietf.org References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> <4BDC0A38.20507@gmx.net> <4BE1B678.8020805@gmx.net> <4BE1EAE3.6030304@gmx.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Hannes Tschofenig , nsis-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 22:22:11 -0000 I will clear my DISCUSS. spt Brian Weis wrote: > Hi Hannes, > > You new wording looks good to me. I have no further comments. > > Thanks, > Brian > > On May 5, 2010, at 3:02 PM, Hannes Tschofenig wrote: > >> Hi Brian, >> >> >> Brian Weis wrote: >>> Hi Hannes, >>> >>> The expanded authorization paragraph is very clear to me, thanks. >>> >>> Regarding protection of the RESERVE` and RESPONSE` hop-by-hop security: >>> >>>>> Don't interior nodes protect RESERVE` and RESPONSE` messages using >>>>> hop-by-hop security, or is that just RESERVE and RESPONSE >>>>> messages? It seems like that would be a simple measure to mitigate >>>>> threats (4) and (5). >>>>> >>>> RESERVE and RESPONSE messages use hop-by-hop security. Keep in mind >>>> that for these two messages the "hop" are ingress and egress; for >>>> the interior nodes these messages cannot be modified. >>> >>> Thanks for the clarification of what constitutes a "hop". So if I >>> understand correctly, only Ingress and Egress routers share a >>> security association for protecting RESERVE and RESPONSE messages. >> Yes. >> >>> >>>> Using hop-by-hop security for RESERVE` and RESPONSE` messages does >>>> not help since the adversary model assumes that one of the interior >>>> nodes is acting maliciously. >>>> >>>> Does this make sense to you? >>> >>> >>> My point was that transport security of RESERVE` and RESPONSE` >>> messages between Interior nodes would also be helpful to protect each >>> Interior node from on-path attackers between themselves. I assume >>> they may have adversaries between them. >> Well. There is actually no other entity between the participating >> interior nodes. In RMD all the nodes in the domain have to participate. >> >>> >>> But I think I understand now that the Security Considerations section >>> is written assuming that only Ingress and Egress devices participate >>> in any kind of security association. >> >> Yes. >> >>> You're not trusting the Interior nodes at all, so they themselves >>> have no security considerations. >> Normally, with a QoS signaling protocol you have to essentially trust >> every node that understands the protocol. In RMD I thought that it >> would be interesting to exploit the fact that you can do better than >> that. >> >>> Could you please clarify the following points in the INTRODUCTION, >>> which would make that clearer? >>> - What is a "hop" with respect to security associations >>> - The security of RMD-QOSM does not depend on interior nodes. (It >>> does say "The focus on intra-domain QoS signaling simplifies trust >>> management and reduces overall complexity." but that's doesn't really >>> go far enough.) >>> - Because the security of RMD-QOSM does not depend on interior nodes, >>> protection of RESERVE` and RESPONSE` messages is not specified. >>> >> Sure. Makes sense. Here is my proposal: >> >> I. INTRODUCTION >> >> A design goal of the RMD-QOSM protocol is to be "lightweight" in terms >> of the number of exchanged signaling message and the amount of state >> established at involved signaling nodes (with and without reduced >> state operation). A side-effect of this design decision is to introduce >> second-class signaling nodes, namely QNE Interior nodes, that are >> restricted >> in their ability to perform QoS signaling actions. Only the QNE >> Ingress and >> the QNE Egress nodes are allowed to initiate certain signaling messages. >> Moreover, RMD focuses on an intra-domain deployment only. >> The above description has the following implications for security: >> >> 1) QNE Ingress and QNE Egress nodes require more security and fault >> protection >> than QNE Interior nodes because their uncontrolled behavior has >> larger >> implications for the overall stability of the network. QNE Ingress >> and >> QNE Egress nodes share a security association and utlize GIST >> security >> for protection of their signaling messages. Intra-domain signaling >> messages used for RMD signaling do not use GIST security and >> therefore >> they do not store security associations. >> >> 2) The focus on intra-domain QoS signaling simplifies trust >> management and >> reduces overall complexity. See Section 2 of RFC 4081 for a more >> detailed >> discussion about the complete set of communication models >> available for >> end-to-end QoS signaling protocols. The security of RMD-QOSM does not >> depend on interior nodes and hence the cryptographic protection of >> intra-domain messages via GIST is not utilized. >> >> It is important to highlight that RMD always uses the message exchange >> shown in Figure 24 >> even if there is no end-to-end signaling session. If the RMD-QOSM is >> triggered based on an E2E signaling exchange then the RESERVE message >> is created by a node outside the RMD domain and will subsequently >> travel further on (e.g., to the data receiver). Such an exchange is >> shown in Figure 3. As such, an evaluation of RMD's security >> always has to be seen as a combination of the two signaling sessions, >> (1) >> and (2) of Figure 24. Note that for the E2E message, such as >> the RESERVE and the RESPONSE message, a single "hop" refers to >> the communication between the QNE Ingress and the QNE Egress >> since QNE Interior nodes do not participate in the exchange. >> >> Ciao >> Hannes >> >>> Thanks, >>> Brian >>> >>> On May 5, 2010, at 11:18 AM, Hannes Tschofenig wrote: >>> >>>> Hi Brian, >>>> >>>> thanks for the quick response. >>>> >>>> Brian Weis wrote: >>>>> Hi Hannes, >>>>> >>>>> On May 1, 2010, at 4:02 AM, Hannes Tschofenig wrote: >>>>> >>>>>> Hey Brian, >>>>>> >>>>>> thanks for your detailed review. >>>>>> >>>>>> I have updated the security consideration section based on your >>>>>> comments. I have added text to describe security threats in more >>>>>> detail, discuss what the assumptions are (trust model), provide >>>>>> security requirements, and updated the part that talks about the >>>>>> specific solution mechanisms. >>>>> >>>>> Thanks! Your re-written security considerations section is very >>>>> much improved. I do have a couple of comments/questions inline below. >>>>> >>>>>> >>>>>> I also added a sentence about the authorization aspect you >>>>>> mentioned. There is nothing special about RMD that would require >>>>>> additional description beyond what is covered in the QoS NSLP and >>>>>> the solutions we had worked on in the context of the Diameter QoS >>>>>> application. The authorizatoin aspect largely happens before RMD >>>>>> signaling is actually triggered. >>>>>> >>>>>> My proposed text can be found below (before Georgios adds it to >>>>>> the draft itself). >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> --------------- >>>>>> >>>>>> >>>>>> 5. Security Considerations >>>>>> >>>>>> I. INTRODUCTION >>>>>> >>>>>> A design goal of the RMD-QOSM protocol is to be "lightweight" in >>>>>> terms >>>>>> of the number of exchanged signaling message and the amount of state >>>>>> established at involved signaling nodes (with and without reduced >>>>>> state operation). A side-effect of this design decision is to >>>>>> introduce >>>>>> second-class signaling nodes, namely QNE Interior nodes, that are >>>>>> restricted >>>>>> in their ability to perform QoS signaling actions. Only the QNE >>>>>> Ingress and >>>>>> the QNE Egress nodes are allowed to initiate certain signaling >>>>>> messages. >>>>>> Moreover, RMD focuses on an intra-domain deployment only. >>>>>> >>>>>> The above description has the following implications for security: >>>>>> >>>>>> 1) QNE Ingress and QNE Egress nodes require more security and >>>>>> fault protection >>>>>> than QNE Interior nodes because their uncontrolled behavior has >>>>>> larger >>>>>> implications for the overall stability of the network. >>>>>> >>>>>> 2) The focus on intra-domain QoS signaling simplifies trust >>>>>> management and >>>>>> reduces overall complexity. See Section 2 of RFC 4081 for a more >>>>>> detailed >>>>>> discussion about the complete set of communication models >>>>>> available for >>>>>> end-to-end QoS signaling protocols. >>>>>> >>>>>> It is important to highlight that RMD always uses the message >>>>>> exchange >>>>>> shown in Figure 24 >>>>>> even if there is no end-to-end signaling session. If the RMD-QOSM is >>>>>> triggered based on an E2E signaling exchange then the RESERVE message >>>>>> is created by a node outside the RMD domain and will subsequently >>>>>> travel further on (e.g., to the data receiver). Such an exchange is >>>>>> shown in Figure 3. As such, an evaluation of RMD's security >>>>>> always has to be seen as a combination of the two signaling >>>>>> sessions, (1) >>>>>> and (2) of Figure 24. >>>>>> >>>>>> QNE QNE QNE QNE >>>>>> Ingress Interior Interior Egress >>>>>> NTLP stateful NTLP stateless NTLP stateless NTLP stateful >>>>>> | | | | >>>>>> | RESERVE (1) | | | >>>>>> +--------------------------------------------->| >>>>>> | RESERVE` (2) | | | >>>>>> +-------------->| | | >>>>>> | | RESERVE` | | >>>>>> | +-------------->| | >>>>>> | | | RESERVE` | >>>>>> | | +------------->| >>>>>> | | | RESPONSE` (2)| >>>>>> |<---------------------------------------------+ >>>>>> | | | RESPONSE (1) | >>>>>> |<---------------------------------------------+ >>>>>> >>>>>> Figure 24: RMD Message Exchange. >>>>>> >>>>>> Authorizing quality of service reservations is accomplished >>>>>> using the AAA framework and the functionality is inherited from >>>>>> the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], >>>>>> and not described again in this document. As a technical >>>>>> solution mechanism Diameter QoS application >>>>>> [I-D.ietf-dime-diameter-qos] may be used. >>>>> >>>>> I assume that it is implied that this authorization is done by the >>>>> Ingress router, as opposed to each Interior node in the path. It >>>>> would be helpful to say this. >>>> >>>> That's true. I extended the paragraph to: >>>> >>>> " >>>> Authorizing quality of service reservations is accomplished >>>> using the AAA framework and the functionality is inherited from >>>> the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp], >>>> and not described again in this document. As a technical >>>> solution mechanism Diameter QoS application >>>> [I-D.ietf-dime-diameter-qos] may be used. The end-to-end >>>> reservation request arriving at the ingress node will >>>> trigger the authorization procedure with the backend AAA >>>> infrastructure. The end-to-end reservation is typically >>>> triggered by a human interaction with a software application, >>>> such as a voice-over-IP client when making a call. When >>>> authorization is successful then no further user initiated >>>> QoS authorization check is expected to be performed within >>>> the RMD domain for the intra-domain reservation. >>>> " >>>> >>>>> >>>>>> >>>>>> >>>>>> II. SECURITY THREATS >>>>>> >>>>>> In the RMD-QOSM, the ingress node constructs both end-to- >>>>>> end and intra-domain signaling messages based on the >>>>>> end-to-end message initiated by the sender end node. The >>>>>> Interior nodes within the RMD network ignore the end-to-end >>>>>> signaling message, but process, modify, and forward the intra-domain >>>>>> signaling messages towards the egress node. In the >>>>>> meantime, resource reservation states are installed, modified >>>>>> or deleted at each interior node along the data path according >>>>>> to the content of each intra-domain signaling message. The >>>>>> edge nodes of an RMD network are critical components >>>>>> that require strong security protection. Therefore, they act >>>>>> as security gateways for incoming and outgoing signaling >>>>>> messages. Moreover, a certain degree of trust has to be placed >>>>>> into Interior nodes within the RMD-QOSM network, such that >>>>>> these nodes can perform signaling message processing and >>>>>> take the necessary actions. >>>>>> >>>>>> With the RMD-QOSM we assume that the >>>>>> ingress and the egress nodes are not controlled by an adversary >>>>>> and the communication between the ingress and the egress >>>>>> nodes is secured using standard GIST security mechanisms >>>>> >>>>> Is there a reference for these security mechanisms? >>>>> >>>> I added a reference to the security consideration section of GIST >>>> (Section 6 of [I-D.ietf-nsis-ntlp]).. >>>> >>>>>> and experiences integrity, replay and confidentiality protection. >>>>>> Note that this only affects messages directly addressed by >>>>>> these two nodes and not any other message that needs to >>>>>> be processed by intermediaries. The SESSION ID object >>>>>> of the end-to-end communication is visible, via GIST, to the >>>>>> Interior nodes. >>>>>> In order to define the security threats that are associated >>>>>> with the RMD-QOSM we consider that an adversary that may be located >>>>>> inside the RMD domain and could >>>>>> drop, delay, duplicate, inject, or modify signaling packets. >>>>>> Depending on location of adversary, we speak about an on-path >>>>>> adversary or an off-path adversary, see also RFC 4081 [RFC4081]. >>>>>> >>>>>> >>>>>> II-A. On-path Adversary >>>>>> >>>>>> The on-path adversary is a node, which supports RMD-QOSM >>>>>> and is able to observe RMD-QOSM signaling message >>>>>> exchanges. >>>>>> >>>>>> 1) Dropping signaling messages >>>>>> >>>>>> An adversary could drop any signaling messages after >>>>>> receiving them. This will cause a failure of reservation >>>>>> request for new sessions or deletion of resource units >>>>>> (bandwidth) for on-going sessions due to states timeout. >>>>>> It may trigger the ingress node to retransmit the >>>>>> lost signaling messages. In this scenario the adversary >>>>>> drops selected signaling messages, for example intra-domain reserve >>>>>> messages. In the RMD-QOSM, the retransmission >>>>>> mechanism can be provided at the ingress node >>>>>> to make sure that signaling messages can reach the >>>>>> egress node. However, the retransmissions triggered by >>>>>> the adversary dropping messages may cause certain >>>>>> problems. Therefore, it is recommended to disable the use >>>>>> of retransmissions in the RMD-QOSM aware network. >>>>>> >>>>>> 2) Delaying Signaling Messages >>>>>> >>>>>> Any signaling message could be delayed by an adversary. >>>>>> For example, if RESERVE` messages >>>>>> are delayed over the duration of the refresh period then the >>>>>> resource units >>>>>> (bandwidth) reserved along the nodes for corresponding >>>>>> sessions will be removed. In this situation, the ingress >>>>>> node does not receive the RESPONSE within a certain >>>>>> period, and considers that the signaling message is >>>>>> failed, which may cause a retransmission of the ’failed’ >>>>>> message. The egress node may distinguish between the >>>>>> two messages, i.e., the delayed message and the retransmitted >>>>>> message, and it could take a proper response. >>>>>> However, interior nodes suffer from this retransmission >>>>>> and they may reserve twice the resource units (bandwidth) >>>>>> requested by the ingress node. >>>>> >>>>> Can this threat be generalized from "twice" to "N times", if the >>>>> message is retransmitted N times? >>>>> If so, it seems like a serious threat. Can the mitigation for >>>>> Replayed Signaling Messages (i.e., storing values) be used here. >>>>> Actually, from the description a retransmitted signaling message >>>>> seems indistinguishable from a replayed signaling message. >>>>> >>>> For interior nodes it is not possible to distinguish replays. The >>>> only entities that detect the replays are edge devices. So, my >>>> proposal is to let the egress detect and to alert about the >>>> potential problem. >>>> >>>> >>>>>> >>>>>> 3) Replaying Signaling Messages >>>>>> >>>>>> An adversary may want to replay signaling messages. >>>>>> It first stores the >>>>>> received messages and decides when to replay these >>>>>> message and at what rate (packets/per seconds). >>>>>> When the RESERVE` message >>>>>> carried a RII object, the egress will reply with a >>>>>> RESPONSE` message towards the ingress node. The ingress >>>>>> node can then detect replays by comparing the value of >>>>>> RII in the RESPONSE` messages with the stored value. >>>>>> >>>>>> 4) Injecting Signaling Messages >>>>>> >>>>>> Similar to the replay-attack scenario, the adversary may >>>>>> store a part of the information carried by signaling >>>>>> messages, for example, the RSN object. When the >>>>>> adversary injects signaling messages, it puts the stored >>>>>> information together with its own generated parameters >>>>>> (Bandwidth, RII, etc.) into the injected messages and >>>>>> then sends them out. Interior nodes will process these >>>>>> messages by default, reserve the requested resource units >>>>>> (bandwidth) and pass them to downstream nodes. It >>>>>> may happen that the resource units (bandwidth) on the >>>>>> Interior nodes are exhausted if these injected messages >>>>>> consume much bandwidth. >>>>>> >>>>>> 5) Modifying Signaling Messages >>>>>> >>>>>> On-path adversaries are capable of modifying any part >>>>>> of the signaling message. For example, the adversary >>>>>> can modify the , and parameters >>>>>> of the RMD-QSPEC messages. The egress node >>>>>> will then use the SESSION ID and subsequently the >>>>>> BOUND SESSION ID objects to refer to that flow >>>>>> to be terminated or set to lower priority. It is also >>>>>> possible for the adversary to modify the >>>>>> and/or parameter, which could cause >>>>>> a modification of an amount of the requested resource >>>>>> units (bandwidth) changes. >>>>> >>>>> Don't interior nodes protect RESERVE` and RESPONSE` messages using >>>>> hop-by-hop security, or is that just RESERVE and RESPONSE >>>>> messages? It seems like that would be a simple measure to mitigate >>>>> threats (4) and (5). >>>>> >>>> RESERVE and RESPONSE messages use hop-by-hop security. Keep in mind >>>> that for these two messages the "hop" are ingress and egress; for >>>> the interior nodes these messages cannot be modified. >>>> >>>> Using hop-by-hop security for RESERVE` and RESPONSE` messages does >>>> not help since the adversary model assumes that one of the interior >>>> nodes is acting maliciously. >>>> >>>> Does this make sense to you? >>>> >>>>>> II-B. Off-path Adversary >>>>>> >>>>>> In this case the adversary is not located on-path and it >>>>>> does not participate in the exchange of RMD-QOSM signaling >>>>>> messages, and therefore is unable to eavesdrop signaling >>>>>> messages. Hence, the adversary does not know valid RIIs, >>>>>> RSNs, SESSION IDs. Hence, the adversary has to generate >>>>>> new parameters and constructs new signaling messages. Since >>>>>> Interior nodes operate in reduced state mode, >>>>>> injected signaling messages are treated as new once, which >>>>>> causes Interior nodes to allocate additional reservation state. >>>>>> >>>>>> >>>>>> III. SECURITY REQUIREMENTS >>>>>> >>>>>> The following security requirements are set as goals for the >>>>>> intra-domain communication, namely: >>>>>> >>>>>> * Nodes, which are never supposed to participate in the NSIS >>>>>> signaling >>>>>> exchange, must not interfere with QNE Interior nodes. Off-path >>>>>> nodes (off-path with regard to the path taken by a particular >>>>>> signaling message exchange) must not be able to interfere with >>>>>> other on-path signaling nodes. >>>>>> >>>>>> * The actions allowed by a QNE Interior node should be minimal (i.e., >>>>>> only those specified by the RMD-QOSM). For example, only the QNE >>>>>> Ingress and the QNE Egress nodes are allowed to initiate certain >>>>>> signaling messages. QNE Interior nodes are, for example, allowed to >>>>>> modify certain signaling message payloads. >>>>>> >>>>>> Note that the term `interfere` refers to all sorts of security >>>>>> threats, such as denial of service, spoofing, replay, signaling >>>>>> message injection, etc. >>>>>> >>>>>> III. SECURITY MECHANISMS >>>>> >>>>> Nit: should be "IV." >>>> Yup. >>>> >>>>> >>>>>> >>>>>> An important security mechanism that was >>>>>> built into RMD-QOSM was the ability to tie the end-to-end >>>>>> RESERVE and the RESERVE` messages >>>>>> together using the BOUND SESSION ID and to allow the >>>>>> ingress node to match the RESERVE` >>>>>> with the RESPONSE` by using the >>>>>> RII. These mechanisms enable the edge nodes to detect unexpected >>>>>> signaling messages. >>>>>> >>>>>> We assume that the RESERVE/RESPONSE is sent with hop-by-hop >>>>>> channel security provided by GIST and protected between the QNE >>>>>> Ingress and the QNE Egress. >>>>> >>>>> If the RESERVE/RESPONSE messages are protected hop-by-hop, why >>>>> can't RESERVE`/RESPONSE` messages? Or does hop-by-hop mean that >>>>> only the ingress and egress devices are "hops" and share keys? >>>>> >>>> See response above. >>>> >>>> Ciao >>>> Hannes >>>> >>>>> Thanks, >>>>> Brian >>>>> >>>>>> GIST security mechanisms MUST be used >>>>>> to offer authentication, >>>>>> integrity, and replay protection. Furthermore, encryption MUST be >>>>>> used >>>>>> to >>>>>> prevent an adversary located along the path of the RESERVE >>>>>> message to learn information about the session that can later be used >>>>>> to inject a RESERVE` message. >>>>>> >>>>>> The following messages need to be mapped to >>>>>> each other to make sure that the occurrence of one message is not >>>>>> without the other one: >>>>>> >>>>>> a) the RESERVE and the RESERVE` relate to each other at the QNE >>>>>> Egress and >>>>>> >>>>>> b) the RESPONSE and the RESERVE relate to each other at the QNE >>>>>> Ingress and >>>>>> >>>>>> c) the RESERVE` and the RESPONSE` relate to each other. The RII is >>>>>> carried in the RESERVE` message and the RESPONSE` message that is >>>>>> generated by the QNE Egress node contains the same RII as the >>>>>> RESERVE`. The RII can be used by the QNE Ingress to match the >>>>>> RESERVE` with the RESPONSE`. The QNE Egress is able to determine >>>>>> whether the RESERVE` was created by the QNE Ingress node since the >>>>>> intra-domain session, which sent the RESERVE`, is bound to an end-to- >>>>>> end session via the BOUND_SESSION_ID value included in the intra- >>>>>> domain QoS-NSLP operational state maintained at the QNE Egress. >>>>>> >>>>>> The RESERVE and the RESERVE` message are tied together using the >>>>>> BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end >>>>>> QoS-NSLP operational states maintained at the QNE edges, see Section >>>>>> 4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a >>>>>> corresponding RESERVE. The SESSION_ID can fulfill this purpose quite >>>>>> well if the aim is to provide protection against off-path adversaries >>>>>> that do not see the SESSION_ID carried in the RESERVE and the >>>>>> RESERVE` messages. >>>>>> >>>>>> If, however, the path changes (due to re-routing or due to mobility) >>>>>> then an adversary could inject RESERVE` messages (with a previously >>>>>> seen SESSION_ID) and could potentially cause harm. >>>>>> >>>>>> An off-path adversary can, of course, create RESERVE` messages that >>>>>> cause intermediate nodes to create some state (and cause other >>>>>> actions) but the message would finally hit the QNE Egress node. The >>>>>> QNE Egress node would then be able to determine that there is >>>>>> something going wrong and generate an error message. >>>>>> >>>>>> The severe congestion handling can be triggered by intermediate nodes >>>>>> (unlike other messages). In many cases, however, intermediate nodes >>>>>> experiencing congestion use refresh messages modify the and >>>>>> parameters of the message. These messages are still >>>>>> initiated by the QNE Ingress node and carry the SESSION_ID. The QNE >>>>>> Egress node will use the SESSION_ID and subsequently the >>>>>> BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP operational >>>>>> state, to refer to a flow that might be terminated. The >>>>>> aspect of intermediate nodes initiating messages for severe >>>>>> congestion handling is for further study. >>>>>> >>>>>> QNE Ingress QNE Interior QNE Interior QNE Egress >>>>>> NTLP stateful NTLP stateless NTLP stateless NTLP stateful >>>>>> | | | | >>>>>> | REFRESH RESERVE` | | >>>>>> +-------------->| REFRESH RESERVE` | >>>>>> | (+RII) +-------------->| REFRESH RESERVE` >>>>>> | | (+RII) +------------->| >>>>>> | | | (+RII) | >>>>>> | | | | >>>>>> | | | REFRESH | >>>>>> | | | RESPONSE`| >>>>>> |<---------------------------------------------+ >>>>>> | | | (+RII) | >>>>>> >>>>>> Figure 25: RMD REFRESH message exchange >>>>>> >>>>>> During the refresh procedure a RESERVE` creates a RESPONSE`, see >>>>>> Figure 25. The RII is carried in the RESERVE` message and the >>>>>> RESPONSE` message that is generated by the QNE Egress node contains >>>>>> the same RII as the RESERVE`. >>>>>> >>>>>> The RII can be used by the QNE Ingress to match the RESERVE` with the >>>>>> RESPONSE`. >>>>>> >>>>>> A further aspect is marking of data traffic. Data packets can be >>>>>> modified by an intermediary without any relationship to a signaling >>>>>> session (and a SESSION_ID). The problem appears if an off-path >>>>>> adversary injects spoofed data packets. >>>>>> >>>>>> >>>>>> The adversary thereby needs to spoof data packets that relate to the >>>>>> flow identifier of an existing end-to-end reservation that SHOULD be >>>>>> terminated. Therefore the question arises how an off-path adversary >>>>>> SHOULD create a data packet that matches an existing flow identifier >>>>>> (if a 5-tuple is used). Hence, this might not turn out to be simple >>>>>> for an adversary unless we assume the previously mentioned >>>>>> mobility/re-routing case where the path through the network changes >>>>>> and the set of nodes that are along a path changes over time. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Brian Weis 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. >>>>>>> >>>>>>> This document describes an NSIS QoS Model for networks that use >>>>>>> the Resource Management in Diffserv (RMD) concept. It describes >>>>>>> RMD-QOSM, which are new payloads sent using the GISP signaling >>>>>>> mechanism, where the new payloads request or reserve resources. A >>>>>>> number of data flows are discussed, depending on whether nodes >>>>>>> within a network boundary participate in the protocol or not. >>>>>>> >>>>>>> The Security Considerations section covers the following topics: >>>>>>> - Byzantine adversaries (i.e., participants taken over by an >>>>>>> adversary) are a general problem, but this section intends to >>>>>>> discuss additional threats as a result of the new protocol. There >>>>>>> is an extensive discussion of on-path and off-path adversaries, >>>>>>> which seems to intend to be addressing Byzantine adversaries. >>>>>>> - RMD-QOSM is claimed to be lightweight, with different routers >>>>>>> allowed certain operations dependant on the role a router plays >>>>>>> in the system. E.g., only Ingress/Egress nodes are allowed to >>>>>>> initiate certain signaling messages. >>>>>>> - RMD-QOSM "relies on the security support that is provided by >>>>>>> the bounded end-to-end session, which is running between the >>>>>>> boundaries of the RMD domain", but doesn't mandate that security >>>>>>> support. >>>>>>> >>>>>>> The existing text is helpful, but not sufficient. The following >>>>>>> points are suggestions to improve this section. >>>>>>> >>>>>>> 1. The statement at the beginning of Security Considerations >>>>>>> discusses adversaries taking over a router, but the new threats >>>>>>> are not very clear. Are the authors considering that security >>>>>>> associations are revealed, that reservation data routed to a >>>>>>> particular router can be changed or forged, or something else? >>>>>>> >>>>>>> 2. The trust model used by RMD-QOSM is hinted at in the >>>>>>> discussion of on-path and off-path adversaries, but a discussion >>>>>>> of exactly what devices are trusted and what they're trusted to >>>>>>> do would be helpful. For example, is every interior router in the >>>>>>> network is trusted to handle any particular RESERVE or RESERVE` >>>>>>> message? If not, then how are the paths setup so that only >>>>>>> authorized routers will see a particular message? On the other >>>>>>> hand, if routing is used to route the messages then it would seem >>>>>>> that any router must be authorized to handle messages happened to >>>>>>> be routed to them -- but then it isn't clear that there can be a >>>>>>> difference between an "on-path" and "off-path" adversary. >>>>>>> >>>>>>> 3. Another dimension of trust model is the fact that >>>>>>> ingress/egress routers seem to trust each other more than they >>>>>>> trust interior nodes. This seems evidenced by the fact that >>>>>>> RESERVE messages (Figure 24) don't seem to be intended to be >>>>>>> modified by the interior routers. In the case of probes, I would >>>>>>> expect that this would be especially important, but probes do not >>>>>>> seem to be specifically discussed in this section. >>>>>>> >>>>>>> 4. There don't seem to be any actual security requirements or >>>>>>> recommendations made on GIST messaging. As such, it isn't clear >>>>>>> that attackers that have not taken over a participant (i.e., a >>>>>>> man in the middle) are in any way foiled. I would expect to see >>>>>>> more MUSTs and SHOULDs in this section regarding message >>>>>>> security. There are statements in the I-D such as "In the >>>>>>> situation a security association exists" and "If we assume that >>>>>>> the RESERVE/RESPONSE is sent with hop-by-hop channel security". >>>>>>> There should be some description of the threats to the messaging >>>>>>> by a non-participant, and stating what available mechanisms MUST >>>>>>> or SHOULD be used. >>>>>>> >>>>>>> 5. Since roles seem to be an important part of the security >>>>>>> considerations, it would be helpful to see discussion of the >>>>>>> different threats & requirements on the ingress/egress routers >>>>>>> and the internal routers in their different roles. >>>>>>> >>>>>>> 6. An important service of RMD-QOSM is admission control, but >>>>>>> there doesn't seem to be any discussion of how the ingress >>>>>>> routers determine whether or not reservation requests given to >>>>>>> them are valid. I would have thought that is of particular >>>>>>> importance, but if it's considered out of scope this section >>>>>>> might mention that fact. >>>>>> >>>>>>> >>>>>>> Hope that helps, >>>>>>> Brian >>>>>>> _______________________________________________ >>>>>>> secdir mailing list >>>>>>> secdir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/secdir >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From tena@huawei.com Wed May 5 19:01:06 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382CE3A6860 for ; Wed, 5 May 2010 19:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.875 X-Spam-Level: X-Spam-Status: No, score=-97.875 tagged_above=-999 required=5 tests=[AWL=-1.993, BAYES_50=0.001, FAKE_REPLY_C=2.012, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQW+97xbu47c for ; Wed, 5 May 2010 19:01:05 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BC2053A67AC for ; Wed, 5 May 2010 19:01:04 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1Z002AE6X57U@szxga03-in.huawei.com> for secdir@ietf.org; Thu, 06 May 2010 10:00:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1Z002TP6X5EJ@szxga03-in.huawei.com> for secdir@ietf.org; Thu, 06 May 2010 10:00:41 +0800 (CST) Received: from z00147053k ([10.70.39.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1Z002ZF6X3FR@szxml04-in.huawei.com> for secdir@ietf.org; Thu, 06 May 2010 10:00:41 +0800 (CST) Date: Thu, 06 May 2010 10:00:39 +0800 From: Tina TSOU To: draft-ietf-mext-flow-binding@tools.ietf.org, secdir@ietf.org Message-id: <8188CB2834004632850B73CB7F6EDD84@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: multipart/alternative; boundary="Boundary_(ID_dB2uQgYa1anwoTMt5GuUDA)" X-Priority: 3 X-MSMail-priority: Normal Cc: mext-chairs@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mext-flow-binding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 02:01:06 -0000 This is a multi-part message in MIME format. --Boundary_(ID_dB2uQgYa1anwoTMt5GuUDA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT The Security Considerations section must at least point to an RFC in which the relevant security analysis for binding updates and acknowledgements is documented. The authors may consider adding the following text: "This specification does not open up new fundamental lines of attack on communications between the MN and its correspondent nodes. However, it allows attacks of a finer granularity than those on the basic binding update. For instance, the attacker can divert or replicate flows of special interest to the attacker to an address of the attacker's choosing, if the attacker is able to impersonate the MN or modify a binding update sent by the MN. Hence it becomes doubly critical that authentication and integrity services are applied to binding updates." B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: Tina TSOU To: secdir@ietf.org ; draft-ietf-mext-flow-binding@tools.ietf.org Cc: mext-chairs@tools.ietf.org Sent: Wednesday, May 05, 2010 5:45 PM Subject: Re: Secdir review of draft-ietf-mext-flow-binding-06 Resending to the correct email addresses of the authors... ----- Original Message ----- From: Tina TSOU To: secdir@ietf.org Cc: draft-ietf-mext-flow-binding-06@tools.ietf.org ; mext-chairs@tools.ietf.org Sent: Wednesday, May 05, 2010 5:05 PM Subject: Secdir review of draft-ietf-mext-flow-binding-06 Hi, 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. Some of my comments are following. Comment 1: The title of this document focuses on flow binding in Mobile IPv6 and NEMO, However it is not clear how flow binding is supported in the NEMO? Is the mobile router operation in NEMO same as mobile node operation in Mobile IPv6? Comment 2: Is flow summary mobility option is one sub-option of Flow Identification Mobility Option or one independent new mobility option? Comment 3: Should the HA, CN and MAP all support this specification? If HA does not support, how to direct inbound flows to specific addresses since one or more flows may bind to a care-of address? B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_dB2uQgYa1anwoTMt5GuUDA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
The Security Considerations section must at least point to an RFC in which the
relevant security analysis for binding updates and acknowledgements is documented.

The authors may consider adding the following text:

"This specification does not open up new fundamental lines of attack on
communications between the MN and its correspondent nodes. However, it allows
attacks of a finer granularity than those on the basic binding update. For
instance, the attacker can divert or replicate flows of special interest to the
attacker to an address of the attacker's choosing, if the attacker is able to
impersonate the MN or modify a binding update sent by the MN. Hence it becomes
doubly critical that authentication and integrity services are applied to
binding updates."
 
 
----- Original Message -----
From: Tina TSOU
Sent: Wednesday, May 05, 2010 5:45 PM
Subject: Re: Secdir review of draft-ietf-mext-flow-binding-06

Resending to the correct email addresses of the authors...
 
----- Original Message -----
From: Tina TSOU
Sent: Wednesday, May 05, 2010 5:05 PM
Subject: Secdir review of draft-ietf-mext-flow-binding-06

Hi,
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.
Some of my comments are following.
 
Comment 1:
The title of this document focuses on flow binding in Mobile IPv6 and NEMO, However it is not clear how flow binding is supported in the NEMO? Is the mobile router operation in NEMO same as mobile node operation in Mobile IPv6?
Comment 2:
Is flow summary mobility option is one sub-option of Flow Identification Mobility Option or one independent new mobility option?
 
Comment 3:
Should the HA, CN and MAP all support this specification? If HA does not support, how to direct inbound flows to specific addresses since one or more flows may bind to a care-of address?
 
 

--Boundary_(ID_dB2uQgYa1anwoTMt5GuUDA)-- From tlyu@mit.edu Wed May 5 20:16:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A913A69B5; Wed, 5 May 2010 20:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.556 X-Spam-Level: X-Spam-Status: No, score=0.556 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3pshOT55GJj; Wed, 5 May 2010 20:16:48 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id B38123A69AD; Wed, 5 May 2010 20:16:47 -0700 (PDT) X-AuditID: 12074423-b7c0bae0000030f0-2d-4be234925965 Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id 11.FC.12528.29432EB4; Wed, 5 May 2010 23:16:34 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o463GWlG024739; Wed, 5 May 2010 23:16:32 -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.6/8.12.4) with ESMTP id o463GT14002159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 May 2010 23:16:30 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o463GTBP022992; Wed, 5 May 2010 23:16:29 -0400 (EDT) To: Paul Hoffman References: From: Tom Yu Date: Wed, 05 May 2010 23:16:29 -0400 Message-ID: Lines: 32 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAARQMCDE= Cc: ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-ikev2bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-ipsecme-ikev2bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 03:16:49 -0000 Paul Hoffman writes: > At 1:23 AM -0400 5/4/10, Tom Yu wrote: > >>The lengthy paragraph warning about non-key-generating EAP methods is >>mostly unchanged from RFC 4306. I do wonder if channel bindings would >>help with non-key-generating EAP methods tunneled in protected >>channels, but am not sufficiently familiar with EAP to know whether >>this is feasible. (non-key-generating EAP methods might not have any >>way to perform the additional necessary authentication to achieve >>channel binding) > > Channel bindings might or might not help here, depending on the current precise definition of "channel bindings". Trying to wind this into a bis document didn't seem prudent, given the loose state of the definition. I just checked, and RFC 5056 ("On the Use of Channel Bindings to Secure Channels") deliberately chose to exclude EAP channel bindings from its recommendations due to the difficulty of meaningfully identifying the lower-level channel over which EAP runs. >>The SHOULD in RFC 4306 in the sentence beginning "Implementers SHOULD >>describe the vulnerabilities of non-key-generating EAP methods..." was >>demoted to a non-capitalized form. Is this intentional? If so, what >>is the rationale? > > There is no interoperability effect of implementers describing > something, and the security aspects are not clear. This seemed like > an over-shooting of RFC 2119 language. One change that would bring it back into a RFC 2119 scope is making a recommendation such as "Implementations SHOULD default to disabling the use of non-key-generating EAP methods", as that recommendation would then have a useful security impact. From derek@ihtfp.com Thu May 6 18:34:26 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884953A68AD; Thu, 6 May 2010 18:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM2D0Fw4yMj1; Thu, 6 May 2010 18:34:25 -0700 (PDT) Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id 37F8D3A6890; Thu, 6 May 2010 18:34:23 -0700 (PDT) Received: from pgpdev.ihtfp.org (unknown [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id A01828B4005; Thu, 6 May 2010 21:34:08 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.3/Submit) id o471Y5Xp018024; Thu, 6 May 2010 21:34:05 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Thu, 06 May 2010 21:34:05 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: wangshuaiyu@chinamobile.com, magnus.westerlund@ericsson.com, karl.hellwig@ericsson.com, ingemar.s.johansson@ericsson.com, duanxiaodong@chinamobile.com, avt-chairs@tools.ietf.org Subject: [secdir] sec-dir review of draft-ietf-avt-rtp-gsm-hr-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 01:34:26 -0000 Hi, 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 specifies the payload format for packetization of the GSM Half-Rate speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. After reading this draft I feel that the authors have conveyed all necessary security considerations that this codec adds to RTP. Therefore, I find no security issues with this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From shanna@juniper.net Thu May 6 19:01:34 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AB73A68B9; Thu, 6 May 2010 19:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYwJaXmd2knt; Thu, 6 May 2010 19:01:33 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 510563A683A; Thu, 6 May 2010 19:00:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS+N0SqZolZqw07Wt1BRj5tJV+9Ei56M3@postini.com; Thu, 06 May 2010 19:01:08 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 6 May 2010 18:58:33 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 6 May 2010 21:58:33 -0400 From: Stephen Hanna To: "secdir@ietf.org" , "iesg@ietf.org" , "jmpolk@cisco.com" , "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "bob.briscoe@bt.com" Date: Thu, 6 May 2010 21:58:31 -0400 Thread-Topic: secdir review for draft-ietf-tsvwg-ecn-tunnel-08 Thread-Index: Acq81GWjk8ZNKlT9TYCK72AfCxOyTQwlIo7Q Message-ID: 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 Subject: [secdir] secdir review for draft-ietf-tsvwg-ecn-tunnel-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 02:01:34 -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 comments. This document describes revised, consistent semantics for setting the ECN (Explicit Congestion Notification) field in the IP header on entry to and exit from any IP in IP tunnel. The document updates RFC 3168 (the main ECN RFC) and RFC 4301 (IPsec) to say that all IP in IP tunnels should follow the new rules for setting the ECN bits. The new rules are similar to the IPsec rules, with the exception of special handling for several previously unused combinations of the ECN bits. These unused combinations provide support for PCN (Pre-Congestion Notification). The primary security concern here is that the ECN bits can serve as a covert channel allowing parties inside and outside the secure area to communicate even though they are not supposed to be able to do so. Malicious parties inside the secure area can set the ECN bits on packets to carefully selected values, exposing 2 bits of information per packet to parties outside the secure area. This covert channel can also operate in the opposite direction (insecure to secure). During the development of RFC 4301, the IPsec Working Group evidently determined that the risks of leaving this small covert channel open are exceeded by the benefits of allowing ECN information to be properly processed end-to-end. Therefore, they elected to permit the ECN bits to be copied from inner to outer IP headers at tunnel ingress (encapsulation) and described how the ECN bits in the outer IP header can be merged into the inner IP header at tunnel egress (decapsulation). The document under review proposes to standardize ECN handling for all IP in IP tunnels with a system that is very similar to the current IPsec behavior. The only difference is that the merging of ECN bits at tunnel egress better accommodates PCN. Because the IPsec Working Group has previously decided that the risks of this small covert channel are exceeded by the benefits of properly functioning ECN and the only change here is to increase the benefits of ECN be supporting PCN, I conclude that the document under review is not problematic from a security perspective. In fact, it can be considered beneficial since it will help avoid dropped packets due to undetected congestion. This improves availability, which is a security characteristic. From Kurt.Zeilenga@Isode.com Fri May 7 12:51:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58523A68ED; Fri, 7 May 2010 12:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNW3lq2ugyDB; Fri, 7 May 2010 12:51:25 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B5E3C3A6940; Fri, 7 May 2010 12:51:24 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 7 May 2010 20:51:11 +0100 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga Date: Fri, 7 May 2010 12:51:09 -0700 Message-Id: <47EEE07C-8E6B-42AC-ACCA-A3CF5FCBB3D1@Isode.com> To: draft-ietf-radext-tcp-transport.all@tools.ietf.org X-Mailer: Apple Mail (2.1078) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IETF , Security Area Directorate Subject: [secdir] SecDir review of draft-ietf-radext-tcp-transport X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 19:51:25 -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 discussions use of RADIUS over TLS (over TCP). This = document is being considered for publication as an Experimental RFC. This document does not discuss the particulars of how TLS is to be used. = It seems left to draft-ietf-radext-radsec, which this document only = informatively references. It may be appropriate to elevate the = reference to draft-ietf-radext-radsec to normative status. I suggest inclusion of text in the Security Considerations section that = specifically refer the reader to draft-ietf-radext-radsec for RADIUS = over TLS specific security considerations, as well as RFC 5246 for = general TLS security considerations. Beyond this, I have no security concerns with transport details this I-D = discusses. Regards, Kurt= From pcain@coopercain.com Sat May 8 07:59:18 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C464A3A6A99; Sat, 8 May 2010 07:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2L0TqD3PqWZ; Sat, 8 May 2010 07:59:18 -0700 (PDT) Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id 1D1073A6A9E; Sat, 8 May 2010 07:59:17 -0700 (PDT) Received: from familyroom ([187.0.211.16]) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id o48EwtBr009979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 May 2010 09:59:03 -0500 Received: from familyroom by familyroom (PGP Universal service); Sat, 08 May 2010 10:59:05 -0500 X-PGP-Universal: processed; by familyroom on Sat, 08 May 2010 10:59:05 -0500 From: "Patrick Cain" To: Date: Sat, 8 May 2010 10:58:55 -0400 Message-ID: <020001caeebe$ffdcd560$ff968020$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcruvnXcvUUchp66RdqcjJnYvLNh+w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 14:59:18 -0000 Hi, 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. About this document: SEcure Neighbor Discovery (SEND) defines the Name Type field in the Trust Anchor option. This document request to IANA the creation and management of a registry for this field. This document also specifies a new Name Type field based on a certificate Subject Key Identifier (SKI). My comments: The document has no major technical shortcomings that I could find. I do note that the new registry value defined in this document relies on SHA-1 (160). This may be a good time to save a few RFC numbers and define a value for the impending other SHA values, like SHA-2, although I'm not so sure they exist in x.509 certificates yet. Pat From roque.lacnic@gmail.com Sat May 8 09:38:47 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB56B3A69F0; Sat, 8 May 2010 09:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWn-1j6pwxIy; Sat, 8 May 2010 09:38:47 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2C2123A6987; Sat, 8 May 2010 09:38:40 -0700 (PDT) Received: by wyb39 with SMTP id 39so124832wyb.31 for ; Sat, 08 May 2010 09:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kXA8MkpxujNVFdDDPsnwW7dZiMG/qVytPlWGH//JBhU=; b=nDN6geqPK3+7xktcC6Q7Bi/hRV6pqLPlH2CZ6SJWD4LrOFfjgOaLu3Eyl9nrbWgIxT /xXQZX8ut0xD9z33BTZoH6NAY/TFEEraFk9w1UcXQ/O4CyWWCoZmyZmVLD43srHCV56t 2c0MjqmHRNp1tpcohm2aYuAxT3xSMjqQujUGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pQwRnAYKNzYxxJ767n0mFYz3XxsQ1+CizA+jCsv8pQTl03sc3TzjBJ4HEelnusQtcw GdAlJIakqGne8blv1DD86rb7bwXxCSztFQaEI3N3RVJWjFDlNcb2cOZiyMURevFfEvSA AK521J17AOLo85DxqwRMbswvnoK++/vFlS2ho= MIME-Version: 1.0 Received: by 10.216.163.67 with SMTP id z45mr1019725wek.26.1273336704793; Sat, 08 May 2010 09:38:24 -0700 (PDT) Received: by 10.216.185.143 with HTTP; Sat, 8 May 2010 09:38:24 -0700 (PDT) In-Reply-To: <020001caeebe$ffdcd560$ff968020$@com> References: <020001caeebe$ffdcd560$ff968020$@com> Date: Sat, 8 May 2010 18:38:24 +0200 Message-ID: From: Roque Gagliano To: Patrick Cain Content-Type: multipart/alternative; boundary=001636426523f7fe97048617cd43 X-Mailman-Approved-At: Sat, 08 May 2010 09:51:32 -0700 Cc: iesg@ietf.org, draft-ietf-csi-send-name-type-registry.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 16:49:40 -0000 --001636426523f7fe97048617cd43 Content-Type: text/plain; charset=ISO-8859-1 Patrick, Thank you for your review. You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and required in draft-ietf-sidr-res-cert Regards, Roque On Sat, May 8, 2010 at 4:58 PM, Patrick Cain wrote: > Hi, > > 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. > > About this document: > > SEcure Neighbor Discovery (SEND) defines the Name Type field in the > Trust Anchor option. This document request to IANA the creation and > management of a registry for this field. This document also > specifies a new Name Type field based on a certificate Subject Key > Identifier (SKI). > > My comments: > > The document has no major technical shortcomings that I could find. > > I do note that the new registry value defined in this document relies on > SHA-1 (160). > This may be a good time to save a few RFC numbers and define a value for > the > impending other SHA values, like SHA-2, although I'm not so sure they exist > in x.509 > certificates yet. > > Pat > > > > --001636426523f7fe97048617cd43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Patrick,

Thank you for your review.

You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and required in=20 draft-ietf-sidr-res-cert

Regards,

Roq= ue

On Sat, May 8, 2010 at 4:58 PM,= Patrick Cain <pcain@coopercain.com> wrote:
Hi,

I have reviewed this document as part of the security directorate's ong= oing
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 ju= st
like any other last call comments.

About this document:

SEcure Neighbor Discovery (SEND) defines the Name Type field in the
=A0 Trust Anchor option. =A0This document request to IANA the creation and=
=A0 management of a registry for this field. =A0This document also
=A0 specifies a new Name Type field based on a certificate Subject Key
=A0 Identifier (SKI).

My comments:

The document has no major technical shortcomings that I could find.

I do note that the new registry value defined in this document relies on SHA-1 (160).
This may be a good time to save a few RFC numbers and define a value for th= e
impending other SHA values, like SHA-2, although I'm not so sure they e= xist
in x.509
certificates yet.

Pat




--001636426523f7fe97048617cd43-- From phoyer@actividentity.com Tue May 11 04:18:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936B23A68C1; Tue, 11 May 2010 04:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.471 X-Spam-Level: X-Spam-Status: No, score=0.471 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGA0WXU6f-a1; Tue, 11 May 2010 04:18:24 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [92.103.229.143]) by core3.amsl.com (Postfix) with ESMTP id 789233A68CC; Tue, 11 May 2010 04:17:04 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id B94A4183947; Tue, 11 May 2010 13:16:52 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 11 May 2010 13:19:42 +0200 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC406890884@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <4BDF2F06.2030406@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SecDir review of draft-ietf-keyprov-pskc-05 Thread-Index: Acrq/eqCAFT9H3o4TRiMNcLiwclhsgF9mL9g References: <4BDF2F06.2030406@inrialpes.fr> From: "Philip Hoyer" To: "Vincent Roca" , , X-Mailman-Approved-At: Tue, 11 May 2010 04:40:50 -0700 Cc: draft-ietf-keyprov-pskc.all@tools.ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-keyprov-pskc-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 11:18:25 -0000 Vincent, Thanks for the review please see comments [PH] inline -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inrialpes.fr]=20 Sent: Monday, May 03, 2010 9:16 PM To: secdir@ietf.org; iesg@ietf.org Cc: draft-ietf-keyprov-pskc.all@tools.ietf.org Subject: SecDir review of draft-ietf-keyprov-pskc-05 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. 1- section 13: about the use of the reserved keywords... On many places I have the feeling that the authors are not sufficiently directive. Two examples (others will follow): * introduction: must =3D> MUST in sentence: "This means that special care must be taken to ensure the confidentiality..." [PH] corrected * 13.1: before the last paragraph of the first solution, add: "Additionally, it is strongly RECOMMENDED that practical implementations use PBESalt and PBEIterationCount when PBE encryption is used." [PH] Added and corrected sentence 2- section 13, about the use of the term "payload" in titles: After reading the introduction of section 13, I understand that "payload" refers to "the information contained within [a PSKC container]". However I have the feeling that the three desired security services are for the whole PSKC container, not only "the information contained within". The titles are therefore a little bit misleading IMHO. [PH] agreed and changed to PSKC 3- section 13.1: rather than "one of the password-based encryption methods provided above", I suggest the authors add an explicit reference to section 6.2. [PH] added explicit reference 4- section 13.1: it is said: "Different PBESalt value per key container should be used for best protection." It's rather ambiguous. It's not clear to me whether it is recommended to use a different PBESalt for each PSKC container, or whether it is recommended to use a different PBESalt when a given PSKC container carries several keys, one PBESalt per key. Also: "should" =3D> "SHOULD" [PH] corrected to " A different PBESalt value per PSKC SHOULD be used for best protection." 5- section 13.1: why isn't the IPsec/ESP not considered also as a third solution to provide the confidentiality, integrity and sender authentication services? Why do the authors only focus on PCKS integrated or TLS solutions? It's not clear. [PH] the authors felt that the usage of the container was intended for application level interchange of keys. Especially in online scenarios where TLS is much more prevalent than IPSec. This does not mean that one could not envisage use of the PSKC over IPsec and hence use IPsec protection mechanisms.=20 6- section 13.1, last but one paragraph: The authors say that TLS offers extra security measures, especially when the digital signature does not encompass the entire payload. I agree, but section 13.1 is dedicated to confidentiality, not to integrity/authenticity verifications. Referring to digital signatures is meaningless in this section. [PH] agreed and removed 7- section 13.1, last paragraph: Instead of: "Validating the secure channel end-points" I'd rather say: "Authenticating". [PH] agreed and corrected=20 8- sections 13.1, 13.2 and 13.3: It is mentioned on several places that TLS can be useful in situations where "the signature of the payload does not encompass the entire payload". Shouldn't the authors RECOMMEND that the digital signature encompass the whole payload instead? It would clarify... This is all the more true if TLS is not used, in which case this is strongly RECOMMENDED. [PH] changed text of section 13.2 "PSKC Integrity" to: " It is RECOMMENDED that for best security practices, the digital signature of the container encompasses the entire PSKC." 9- section 13.3: it is said: "A weaker payload authenticity guarantee may be provided by the transport layer if it is configured to digest each message it transports." Why is this feature necessarily weaker? The source can be authenticated with the same level of security as if it was done by the recipient end. [PH] it is weaker in the sense that the TLS endpoints could differ from the key provisioning endpoints. So in that sense the signature in the message would protect it from message sender to receiver. Typos: * section 13.1 (also section 3): Rather than saying "the portable key container", I suggest the authors either write everything in extenso, or use the PSKC acronym. [PH] changed to PSKC besides in the first sentence of the section. * section 6.3, first sentence: a comma is missing between "element information", making the sentence difficult to understand. [PH] corrected Regards, Vincent From turners@ieca.com Tue May 11 09:10:06 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86DFB3A6D25 for ; Tue, 11 May 2010 09:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpjBbfokabYR for ; Tue, 11 May 2010 09:10:06 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id F04FA3A6D23 for ; Tue, 11 May 2010 09:10:02 -0700 (PDT) Received: (qmail 51875 invoked from network); 11 May 2010 16:09:49 -0000 Received: from thunderfish.local (turners@71.191.14.208 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 11 May 2010 09:09:49 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: sudkxtgVM1nvhnLoma10A1Jwn_0dN0VcaiauQ_WnOnHhI0AkPCH1uYgOWjqpnJN8tLiSivDcuJF_CSrYfeHzXnwTU2rnm3XUKIXBgfCvrMXOLNDDOskMqPrMapSaef2Gp5X5UvETgrVoaHKHlXhMv.Q3PclPfK06r4uecni8EnRpy_nXuBlon.nF2sz1AApuemigsP1gj4GbXxB.YOEyvWMA9cDjt2Jm0ygRoSslEVVqo1tW2_lWBbQCBYGAg_Ux9ivN1OqdHYcR4atbgN7l3o4cOsnMJPhzwGQtCQetJWpxCQiadhyN1s0AHGsPgc2plHr399JL9ro5CQrNmwkrMxa3mBAAkf.ujja.i2.kxjZiJgn6epWJjL1pWEsb9PkllV._ywuZdygw.8BFOo..0Zrx1JOnTo__aFbNf6NGrlV.QtuxVK4QjX1TXg70bzx9Uu423Xsxg0U5saAtj7uqG1YwklNyAmtSG1nOD1qNbQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BE9814D.6040404@ieca.com> Date: Tue, 11 May 2010 12:09:49 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Roque Gagliano References: <020001caeebe$ffdcd560$ff968020$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-csi-send-name-type-registry.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 16:10:06 -0000 Roque, I think what Pat is suggesting that at some point in the future SHA-1 might not be required and then we'd need to do another update to the registry. We could do a little future proofing by including registry entries for SHA-224, SHA-256, SHA-384, and SHA-512 in this I-D. spt Roque Gagliano wrote: > Patrick, > > Thank you for your review. > > You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and > required in draft-ietf-sidr-res-cert > > Regards, > > Roque > > On Sat, May 8, 2010 at 4:58 PM, Patrick Cain > wrote: > > Hi, > > 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. > > About this document: > > SEcure Neighbor Discovery (SEND) defines the Name Type field in the > Trust Anchor option. This document request to IANA the creation and > management of a registry for this field. This document also > specifies a new Name Type field based on a certificate Subject Key > Identifier (SKI). > > My comments: > > The document has no major technical shortcomings that I could find. > > I do note that the new registry value defined in this document relies on > SHA-1 (160). > This may be a good time to save a few RFC numbers and define a value > for the > impending other SHA values, like SHA-2, although I'm not so sure > they exist > in x.509 > certificates yet. > > Pat > > > > From weiler@watson.org Tue May 11 10:36:51 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D953A6985 for ; Tue, 11 May 2010 10:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHUWLaM1F6yo for ; Tue, 11 May 2010 10:36:50 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 8D4B43A69EA for ; Tue, 11 May 2010 10:35:57 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o4BHZkot006479 for ; Tue, 11 May 2010 13:35:46 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o4BHZkjC006476 for ; Tue, 11 May 2010 13:35:46 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 11 May 2010 13:35:46 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 11 May 2010 13:35:46 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 11 May 2010 17:36:51 -0000 A few of the new assignmetns are of docs scheduled for the May 30th telechat (to Dan Harkins, Steve Hanna, Philip Hallam-Baker). Sam Hartman is next in the rotation. As usual, docs on the telechat agendas typically have last calls ending earlier. -- Sam For telechat 2010-05-20 Richard Barnes T 2010-05-18 draft-ietf-csi-send-cert-03 Dave Cridland T 2010-05-18 draft-ietf-marf-base-04 Donald Eastlake T 2010-05-18 draft-ietf-netlmm-mip-interactions-06 Phillip Hallam-Baker T 2010-05-18 draft-ietf-softwire-ipv6-6rd-09 Steve Hanna T 2010-05-18 draft-ietf-syslog-dtls-05 Dan Harkins T 2010-05-18 draft-ietf-yam-5321bis-smtp-pre-evaluation-05 David McGrew T 2010-05-18 draft-turner-encryptedkeypackagecontenttype-algs-02 Nico Williams T 2010-05-18 draft-ietf-opsec-routing-protocols-crypto-issues-04 Tom Yu T 2010-05-18 draft-ietf-avt-rtcp-guidelines-03 Glen Zorn T 2010-05-18 draft-ietf-6lowpan-routing-requirements-06 For telechat 2010-06-03 Tom Yu TR2010-06-01 draft-krishnan-v6ops-teredo-update-07 Larry Zhu T 2010-06-01 draft-santoni-media-type-tsd-00 For telechat 2010-06-17 Stephen Farrell T 2010-06-15 draft-kucherawy-authres-header-b-01 Last calls and special requests: Rob Austein 2010-05-14 draft-ietf-bmwg-protection-term-08 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-05 Alan DeKok 2010-05-12 draft-ietf-netconf-monitoring-12 Shawn Emery 2010-05-17 draft-ietf-mboned-ipv4-uni-based-mcast-06 Tobias Gondrom 2010-05-11 draft-ietf-tsvwg-dtls-for-sctp-05 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows 2010-05-04 draft-ietf-tsvwg-dtls-for-sctp-05 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Sam Weiler 2010-05-19 draft-hoffman-tls-additional-random-ext-01 Brian Weis 2010-05-19 draft-sheffer-emu-eap-eke-06 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 From new-work-bounces@ietf.org Tue May 11 10:30:06 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0243A6D55; Tue, 11 May 2010 10:30:06 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4B58E3A6D01; Tue, 11 May 2010 10:30:02 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100511173002.4B58E3A6D01@core3.amsl.com> Date: Tue, 11 May 2010 10:30:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 11 May 2010 10:54:01 -0700 Subject: [secdir] [New-work] WG Review: Stringprep after IDNA2008 WG (newprep) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 17:30:06 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 18, 2010. Stringprep after IDNA2008 WG (newprep) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-04-23 Chair(s): TBD Applications Area Director(s): Alexey Melnikov Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing Lists: General Discussion: newprep@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/newprep Archive: http://www.ietf.org/mail-archive/web/newprep/current/maillist.html Description of Working Group: Problem Statement The use of non-ASCII strings in Internet protocols requires additional processing to be handled properly. As part of the Internationalized Domain Names (idn) work in 2003, a method for preparation and comparison of internationalized strings was defined and generalized to be re-used by other protocols. This "stringprep" method [RFC 3454] defines the overall framework whereas specific protocols define their own profiles. Known existing IETF profiles are: - The Nameprep profile [RFC 3490] for use in Internationalized Domain Names in Applications (IDNA) - The iSCSI profile [RFC 3722] for use in Internet Small Computer Systems Interface (iSCSI) Names - The Nodeprep and Resourceprep profiles [RFC 3920] for use in the Extensible Messaging and Presence Protocol (XMPP) - The Policy MIB profile [RFC 4011] for use in the Simple Network Management Protocol (SNMP) - The SASLprep profile [RFC 4013] for use in the Simple Authentication and Security Layer (SASL) - The trace profile [RFC 4505] for use with the SASL ANONYMOUS mechanism - The LDAP profile (RFC 4518] for use with LDAP The IAB completed a review of IDN and made recommendations for change [RFC 4690], which triggered a new version of the IDNA protocol called IDNA2008. Whereas IDNA2003 was tied to Unicode 3.2 via stringprep, IDNA2008 does not use the stringprep method, but instead uses an algorithm based on the properties of Unicode characters, which makes it agile to the Unicode database version. The protocols using stringprep need Unicode version agility and therefore need to investigate how to move from the current stringprep approach, with the associated challenges of backward compatibility and migration. Objectives The goal of this group is to assess whether a new method based on the IDNA2008 algorithmic approach is the appropriate path forward for existing stringprep protocols as well as for other application protocols requiring internationalized strings. The group will evaluate if a new generalized framework based on the algorithmic approach is appropriate and, if so, define it. The group will analyze existing stringprep profiles and will do one of the following with regard to each profile: 1. Develop a replacement for the profile in close collaboration with the related protocol working group. 2. Collaborate with another active working group which will be developing the new profile as part of its charter. 3. Advise the authors of profiles for which there is no active working group how to proceed. The group will also define a set of best current practices for preparation and comparison of internationalized strings. Because the framework, profile replacements, and guidelines are very much interrelated, work on them will proceed in parallel as much as possible. In completing its tasks, the working group should collaborate with other teams involved in internationalized identifiers, such as the IETF's IRI and EAI working groups as well as other relevant standards development organizations (e.g., the Unicode Consortium). Deliverables 1. Problem statement / analysis of existing stringprep profiles (Informational). 2. Possible new framework to replace stringprep (Standards Track). 3. Possible replacements for the existing IETF stringprep profiles as listed earlier in this charter (Standards Track). 4. String preparation and comparison guidelines (BCP). Milestones Aug 2010 - Accept problem statement document as a WG item Nov 2010 - Accept framework document as a WG item Nov 2010 - Accept new profile documents as WG items Dec 2010 - Start Working Group Last Call on problem statement document Jan 2011 - Submit problem statement document to the IESG Jan 2011 - Accept guidelines document as a WG item May 2011 - Start Working Group Last Call on framework document May 2011 - Start Working Group Last Call on new profile documents Jun 2011 - Submit framework document to the IESG Jun 2011 - Submit new profile documents to the IESG Jun 2011 - Start Working Group Last Call on guidelines document Aug 2011 - Submit guidelines document to the IESG _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kent@bbn.com Thu May 13 10:12:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452213A6C5C; Thu, 13 May 2010 10:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.535 X-Spam-Level: X-Spam-Status: No, score=0.535 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSuxXsE69bfA; Thu, 13 May 2010 10:12:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 10D7E3A6C50; Thu, 13 May 2010 10:12:44 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58433 helo=[192.168.1.65]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OCbxZ-000Dzr-EE; Thu, 13 May 2010 13:12:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <020001caeebe$ffdcd560$ff968020$@com> Date: Wed, 12 May 2010 14:00:00 -0400 To: Roque Gagliano From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-938351741==_ma============" Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-csi-send-name-type-registry.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 17:12:57 -0000 --============_-938351741==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 6:38 PM +0200 5/8/10, Roque Gagliano wrote: >Patrick, > >Thank you for your review. > >You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and >required in draft-ietf-sidr-res-cert > >Regards, > >Roque Roque, 5280 defines how to use SHA-1, but it does not require use of this specific hash function. 4.2.1.2 says: For CA certificates, subject key identifiers SHOULD be derived from the public key or a method that generates unique values. Two common methods for generating key identifiers from the public key are: ... Other methods of generating unique numbers are also acceptable. So, use of another one-way hash function, e.g., SHA-256 meets the criteria defined above (associated with the "SHOULD") and is consistent with the final comment. CAs need to know which function to use, but RPs just perform comparisons. We could modify the RPKI cert profile (if Geoff and the SIDR WG don't mind) to specify use of SHA-256 for generation of SKI/AKI values. I guess the real issue is whether commonly used software (e.g., OpenSSL) will support this. Steve --============_-938351741==_ma============ Content-Type: text/html; charset="us-ascii" Re: [secdir] secdir review of draft-ietf-csi-send-name-ty
At 6:38 PM +0200 5/8/10, Roque Gagliano wrote:
Patrick,

Thank you for your review.

You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and required in draft-ietf-sidr-res-cert

Regards,
Roque

Roque,

5280 defines how to use SHA-1, but it does not require use of this specific
hash function. 4.2.1.2 says:

   For CA certificates, subject key identifiers SHOULD be derived from the public key or a method that generates unique values.  Two common methods for generating key identifiers from the public key are:

...

Other methods of generating unique numbers are also acceptable.

So, use of another one-way hash function, e.g., SHA-256 meets the criteria defined above (associated with the "SHOULD") and is consistent with the final comment.

CAs need to know which function to use, but RPs just perform comparisons. We could modify the RPKI cert profile (if Geoff and the SIDR WG don't mind) to specify use of SHA-256 for generation of SKI/AKI values. I guess the real issue is whether commonly used software (e.g., OpenSSL) will support this.

Steve
--============_-938351741==_ma============-- From weiler@watson.org Fri May 14 06:29:44 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B39B3A6A84 for ; Fri, 14 May 2010 06:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1350vOlb4JwV for ; Fri, 14 May 2010 06:29:43 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 7B70E3A6ADC for ; Fri, 14 May 2010 06:28:54 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o4EDSiAK029502 for ; Fri, 14 May 2010 09:28:44 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o4EDSh3Q029498 for ; Fri, 14 May 2010 09:28:44 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 14 May 2010 09:28:43 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 14 May 2010 09:28:44 -0400 (EDT) Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 14 May 2010 13:29:44 -0000 The telechat agenda for next week hasn't changed in any interesting ways since I sent assignments on Tuesday, so I'm not sending a new list today. Some of you have gotten private notes about individual documents. -- Sam On Tue, 11 May 2010, Samuel Weiler wrote: > A few of the new assignments are of docs scheduled for the May 30th > telechat (to Dan Harkins, Steve Hanna, Philip Hallam-Baker). Sam > Hartman is next in the rotation. As usual, docs on the telechat > agendas typically have last calls ending earlier. > > -- Sam > > > For telechat 2010-05-20 > > Richard Barnes T 2010-05-18 draft-ietf-csi-send-cert-03 > Dave Cridland T 2010-05-18 draft-ietf-marf-base-04 > Donald Eastlake T 2010-05-18 draft-ietf-netlmm-mip-interactions-06 > Phillip Hallam-Baker T 2010-05-18 draft-ietf-softwire-ipv6-6rd-09 > Steve Hanna T 2010-05-18 draft-ietf-syslog-dtls-05 > Dan Harkins T 2010-05-18 draft-ietf-yam-5321bis-smtp-pre-evaluation-05 > David McGrew T 2010-05-18 draft-turner-encryptedkeypackagecontenttype-algs-02 > Nico Williams T 2010-05-18 draft-ietf-opsec-routing-protocols-crypto-issues-04 > Tom Yu T 2010-05-18 draft-ietf-avt-rtcp-guidelines-03 > Glen Zorn T 2010-05-18 draft-ietf-6lowpan-routing-requirements-06 > > > For telechat 2010-06-03 > > Tom Yu TR2010-06-01 draft-krishnan-v6ops-teredo-update-07 > Larry Zhu T 2010-06-01 draft-santoni-media-type-tsd-00 > > > For telechat 2010-06-17 > > Stephen Farrell T 2010-06-15 draft-kucherawy-authres-header-b-01 > > Last calls and special requests: > > Rob Austein 2010-05-14 draft-ietf-bmwg-protection-term-08 > Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-05 > Alan DeKok 2010-05-12 draft-ietf-netconf-monitoring-12 > Shawn Emery 2010-05-17 draft-ietf-mboned-ipv4-uni-based-mcast-06 > Tobias Gondrom 2010-05-11 draft-ietf-tsvwg-dtls-for-sctp-05 > Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 > David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 > Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 > Catherine Meadows 2010-05-04 draft-ietf-tsvwg-dtls-for-sctp-05 > Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 > Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 > Sam Weiler 2010-05-19 draft-hoffman-tls-additional-random-ext-01 > Brian Weis 2010-05-19 draft-sheffer-emu-eap-eke-06 > Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 > Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 > Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 From hartmans@mit.edu Fri May 14 11:51:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BCA3A68FC; Fri, 14 May 2010 11:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MRhU7AYv8q8; Fri, 14 May 2010 11:51:28 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C3E053A687E; Fri, 14 May 2010 11:51:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 77048201CA; Fri, 14 May 2010 14:51:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 983CC43EE; Fri, 14 May 2010 14:51:14 -0400 (EDT) From: Sam Hartman To: Tom Yu References: Date: Fri, 14 May 2010 14:51:14 -0400 In-Reply-To: (Tom Yu's message of "Wed, 05 May 2010 23:16:29 -0400") 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, ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-ikev2bis.all@tools.ietf.org, Paul Hoffman , iesg@ietf.org Subject: Re: [secdir] review of draft-ietf-ipsecme-ikev2bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 18:51:29 -0000 >>>>> "Tom" == Tom Yu writes: Tom> Paul Hoffman writes: >> At 1:23 AM -0400 5/4/10, Tom Yu wrote: >> >>> The lengthy paragraph warning about non-key-generating EAP >>> methods is mostly unchanged from RFC 4306. I do wonder if >>> channel bindings would help with non-key-generating EAP methods >>> tunneled in protected channels, but am not sufficiently familiar >>> with EAP to know whether this is feasible. (non-key-generating >>> EAP methods might not have any way to perform the additional >>> necessary authentication to achieve channel binding) >> >> Channel bindings might or might not help here, depending on the >> current precise definition of "channel bindings". Trying to wind >> this into a bis document didn't seem prudent, given the loose >> state of the definition. Tom> I just checked, and RFC 5056 ("On the Use of Channel Bindings Tom> to Secure Channels") deliberately chose to exclude EAP channel Tom> bindings from its recommendations due to the difficulty of Tom> meaningfully identifying the lower-level channel over which EAP Tom> runs. OK, so remember that there are two different definitions of channel bindings: EAP channel bindings and RFC 5056 channel bindings. If you don't know the difference, giving up now for this discussion would probably be reasonable:-) EAP channel binding could be used to provide RFC 5056 channel binding for the IKE session, assuming that you could define an RFC 5056 channel binding data appropriate to a under-negotiation IKE session. However, i'm unaware of any EAP methods that do or could easily be made to support EAP channel binding that do not produce a key. It would be possible to use RFC 5056 channel binding (or something like it) to bind an EAP method that did not produce a key to the IKE session if that method produced something similar to channel binding data. No EAP methods today do this: why not make them produce a key instead if you were going to manage to make such a change. In conclusion, I don't think that RFC 5056 or EAP channel binding have much to add to EAP methods that produce no key. From vincent.roca@inrialpes.fr Mon May 17 03:13:47 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3513828C0E3; Mon, 17 May 2010 03:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.272 X-Spam-Level: X-Spam-Status: No, score=-4.272 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS5CTxokazdz; Mon, 17 May 2010 03:13:45 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 1514D3A69A1; Mon, 17 May 2010 03:08:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,247,1272837600"; d="scan'208";a="62933274" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 17 May 2010 12:08:46 +0200 Message-ID: <4BF115AD.5010400@inrialpes.fr> Date: Mon, 17 May 2010 12:08:45 +0200 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Philip Hoyer References: <4BDF2F06.2030406@inrialpes.fr> <5BFE9E473DBFC24CA87F18F29B3F0AC406890884@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC406890884@sur-corp-ex-02.corp.ad.activcard.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-keyprov-pskc.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-keyprov-pskc-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 10:13:47 -0000 Hello Philip, I see we agree on most items (I removed them). Two comments: > 5- section 13.1: > why isn't the IPsec/ESP not considered also as a third > solution to provide the confidentiality, integrity and sender > authentication services? Why do the authors only focus > on PCKS integrated or TLS solutions? It's not clear. > [PH] the authors felt that the usage of the container was intended for > application level interchange of keys. Especially in online scenarios > where TLS is much more prevalent than IPSec. This does not mean that one > could not envisage use of the PSKC over IPsec and hence use IPsec > protection mechanisms. > [VR] I understand. Thanks for the clarification. > 9- section 13.3: it is said: > "A weaker payload authenticity guarantee may be provided by the > transport layer if it is configured to digest each message it > transports." > > Why is this feature necessarily weaker? The source can be > authenticated with the same level of security as if it was > done by the recipient end. > [PH] it is weaker in the sense that the TLS endpoints could differ from > the key provisioning endpoints. So in that sense the signature in the > message would protect it from message sender to receiver. > [VR] Said this way, I fully agree. I suggest you clarify the I-D as well, e.g.: "Authenticity guarantee may be provided by [...]. However, no authenticity verification is possible once [...]. Since the TLS endpoints could differ from the key provisioning endpoints, this solution is weaker than the previous solution that relies on a digital signature of the PSKC." Cheers, Vincent From turners@ieca.com Mon May 17 07:52:08 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CEA43A6A46 for ; Mon, 17 May 2010 07:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ezqaXKh7DUW for ; Mon, 17 May 2010 07:52:08 -0700 (PDT) Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 395003A6A7C for ; Mon, 17 May 2010 07:51:31 -0700 (PDT) Received: (qmail 81977 invoked from network); 17 May 2010 14:51:21 -0000 Received: from thunderfish.local (turners@71.191.0.118 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 17 May 2010 07:51:19 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: fJ0W3D8VM1kuaspxz6wrwA9b65yOIHCQfhinL2ZRsPaRDrPO4kwG.Ge7PKwO7kmfTImRvmc7nIPb1EvBo_KGjqYxpJNyMgQbSNej02Bz4PwM.ifNC50liz_GB1CVlLYI22QgByIQ9x2nvvmnE6LUfbyqjtAVdomEUExkD7bZ.ldPuW2fgcYqQKWI9.kUhbg2dkLkvJj9l4MVptHRM_RZh353bO_6h1JYUzEh8VeuHoR7SlcUHvPMUu1TTvB_npR2HPFsdQezoTVuTS41Wi531lq8xk_xBGGXaSnohy6hs97IKJAmlS76zkY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BF157E6.2050808@ieca.com> Date: Mon, 17 May 2010 10:51:18 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stephen Kent References: <020001caeebe$ffdcd560$ff968020$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, draft-ietf-csi-send-name-type-registry.all@tools.ietf.org, Roque Gagliano , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 14:52:08 -0000 Stephen Kent wrote: > At 6:38 PM +0200 5/8/10, Roque Gagliano wrote: >> Patrick, >> >> Thank you for your review. >> >> You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and >> required in draft-ietf-sidr-res-cert >> >> Regards, >> Roque > > Roque, > > 5280 defines how to use SHA-1, but it does not_ require_ use of this > specific > hash function. 4.2.1.2 says: > > For CA certificates, subject key identifiers SHOULD be derived from > the public key or a method that generates unique values. Two common > methods for generating key identifiers from the public key are: > > ... > > Other methods of generating unique numbers are also acceptable. > > So, use of another one-way hash function, e.g., SHA-256 meets the > criteria defined above (associated with the "SHOULD") and is consistent > with the final comment. > > CAs need to know which function to use, but RPs just perform > comparisons. We could modify the RPKI cert profile (if Geoff and the > SIDR WG don't mind) to specify use of SHA-256 for generation of SKI/AKI > values. I guess the real issue is whether commonly used software (e.g., > OpenSSL) will support this. I'm sure somebody will correct me if I'm wrong. At first, I was encouraged because OpenSSL allows you pick between "the guidelines in RFC3280 or a hex string giving the extension value to include". If you want to follow the standard, then you use the following: subjectKeyIdentifier=hash. But, then I went to the str_lib.c files, part of OpenSSL: SHA_DIGEST_LENGTH, /* ISSUERKEYID: SHA1 digest, 160 bits */ SHA_DIGEST_LENGTH, /* SUBJECTKEYID: SHA1 digest, 160 bits */ So it looks like it's hard coded to use SHA-1. spt From turners@ieca.com Mon May 17 07:52:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B023A67EA for ; Mon, 17 May 2010 07:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDHwD8K+8+iy for ; Mon, 17 May 2010 07:52:57 -0700 (PDT) Received: from smtp111.biz.mail.sp1.yahoo.com (smtp111.biz.mail.sp1.yahoo.com [69.147.92.224]) by core3.amsl.com (Postfix) with SMTP id C762F3A6CB0 for ; Mon, 17 May 2010 07:52:06 -0700 (PDT) Received: (qmail 63138 invoked from network); 17 May 2010 14:51:59 -0000 Received: from thunderfish.local (turners@71.191.0.118 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 17 May 2010 07:51:58 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: NBD.XzAVM1mhaQXM.QEYjZN_IDae69qfq58hkIjKpx0Tzs_YiAJRAUR23zbyUFccY01fkAmXIS77Qd.I9GYuHopt2jEpCpuqnH2_M8UPjHwlit_lVaQmfpfHfxVpKUi62Io2hS2oMh2z4TqGWh4wsIHbmzjKpIATQqCwL3Z1Qym0DYwV3oCU6ekgUjFJMLsOwS2PSrk7RxQ4esSiQFbqR6abHMgpqeByeCSjAC9bf4ybxGaAGSxyELUyYcAdH4nQidlKbPEeh9ZtSyyBpEqvHUyiHXL.cnBh_EbfwUolZ5pK1nQ55B_0q7QUPkhPQbsk.ed8dkfNQsnRHbJq_1II7g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BF1580C.70407@ieca.com> Date: Mon, 17 May 2010 10:51:56 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Roque Gagliano References: <020001caeebe$ffdcd560$ff968020$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, draft-ietf-csi-send-name-type-registry.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 14:52:57 -0000 That is what, I believe, Pat was asking for. spt Roque Gagliano wrote: > Stephen/ Patrick/Sean, > > Thank you for your comments. What about adding the following extra > numbers to the registry?: > > +---------+----------------------------------------------------+ > | Value | Description | > +---------+----------------------------------------------------+ > | 0 | Reserved | > | | | > | 1 | DER Encoded X.501 Name (RFC 3971) | > | | | > | 2 | FQDN (RFC 3971) | > | | | > | 3 | SHA-1 Subject Key Identifier (SKI) ( Section 3 ) | > | | | > | 4 | SHA-224 Subject Key Identifier (SKI) ( Section 3 ) | > | | | > | 5 | SHA-256 Subject Key Identifier (SKI) ( Section 3 ) | > | | | > | 6 | SHA-384 Subject Key Identifier (SKI) ( Section 3 ) | > | | | > | 7 | SHA-512 Subject Key Identifier (SKI) ( Section 3 ) | > | | | > | 253-254 | Experimental use | > | | | > | 255 | Reserved | > +---------+----------------------------------------------------+ > > This way we stay ready if SIDR certs uses some of these hashes > functions in the future. > > regards, > > Roque > > > On Wed, May 12, 2010 at 8:00 PM, Stephen Kent wrote: >> At 6:38 PM +0200 5/8/10, Roque Gagliano wrote: >> >> Patrick, >> >> Thank you for your review. >> >> You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and >> required in draft-ietf-sidr-res-cert >> >> Regards, >> >> Roque >> >> Roque, >> 5280 defines how to use SHA-1, but it does not require use of this specific >> hash function. 4.2.1.2 says: >> For CA certificates, subject key identifiers SHOULD be derived from the >> public key or a method that generates unique values. Two common methods for >> generating key identifiers from the public key are: >> ... >> Other methods of generating unique numbers are also acceptable. >> So, use of another one-way hash function, e.g., SHA-256 meets the criteria >> defined above (associated with the "SHOULD") and is consistent with the >> final comment. >> CAs need to know which function to use, but RPs just perform comparisons. We >> could modify the RPKI cert profile (if Geoff and the SIDR WG don't mind) to >> specify use of SHA-256 for generation of SKI/AKI values. I guess the real >> issue is whether commonly used software (e.g., OpenSSL) will support this. >> Steve > From roque.lacnic@gmail.com Sun May 16 10:37:13 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4023A68E1; Sun, 16 May 2010 10:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFRUdLvzzBgd; Sun, 16 May 2010 10:37:12 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 16B2A3A67A6; Sun, 16 May 2010 10:37:11 -0700 (PDT) Received: by wwb28 with SMTP id 28so1900220wwb.31 for ; Sun, 16 May 2010 10:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9URZcsQUCj1bJm2MUeaR9VYD0HR9/Y9CRLdOKRAbgSE=; b=cF2XftDdW/psB9PGHhZRN40LrDmQyYWXPKa+ZLk9pPEaRiptXFc9UJUDfZ1m3orIIu F//Yz07LMnhEH0t6ijBPVMIF8hY/fRulcv99rYRkk+K6Lvu7inVgTHGy5v6Kgjbkp2xf fQipPenP8bloEtANl+QtBFZTyfi6BRMiXQCdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e1P7mj6dB2pmXUtZ0zZKo1491ZZE7H4aeay+OIPKiIJXjtMN19r/XadLaWI5K0lLEq k9MmeDBlXRWsRENdfnJ6hYjpxYGyc/ql3YUp6s3Sya8vj8pYbUkcPT9/zxPaL2istQkm UPBtAxq0cL1NqhM/tvDfYICSVDOUpjLnYZ2o4= MIME-Version: 1.0 Received: by 10.216.89.207 with SMTP id c57mr2481518wef.60.1274031420225; Sun, 16 May 2010 10:37:00 -0700 (PDT) Received: by 10.216.185.143 with HTTP; Sun, 16 May 2010 10:37:00 -0700 (PDT) In-Reply-To: References: <020001caeebe$ffdcd560$ff968020$@com> Date: Sun, 16 May 2010 19:37:00 +0200 Message-ID: From: Roque Gagliano To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 17 May 2010 10:40:52 -0700 Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-csi-send-name-type-registry.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 17:37:13 -0000 Stephen/ Patrick/Sean, Thank you for your comments. What about adding the following extra numbers to the registry?: +---------+----------------------------------------------------+ | Value | Description | +---------+----------------------------------------------------+ | 0 | Reserved | | | | | 1 | DER Encoded X.501 Name (RFC 3971) | | | | | 2 | FQDN (RFC 3971) | | | | | 3 | SHA-1 Subject Key Identifier (SKI) ( Section 3 ) | | | | | 4 | SHA-224 Subject Key Identifier (SKI) ( Section 3 ) | | | | | 5 | SHA-256 Subject Key Identifier (SKI) ( Section 3 ) | | | | | 6 | SHA-384 Subject Key Identifier (SKI) ( Section 3 ) | | | | | 7 | SHA-512 Subject Key Identifier (SKI) ( Section 3 ) | | | | | 253-254 | Experimental use | | | | | 255 | Reserved | +---------+----------------------------------------------------+ This way we stay ready if SIDR certs uses some of these hashes functions in the future. regards, Roque On Wed, May 12, 2010 at 8:00 PM, Stephen Kent wrote: > At 6:38 PM +0200 5/8/10, Roque Gagliano wrote: > > Patrick, > > Thank you for your review. > > You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and > required in draft-ietf-sidr-res-cert > > Regards, > > Roque > > Roque, > 5280 defines how to use SHA-1, but it does not require use of this specif= ic > hash function. 4.2.1.2 says: > =A0=A0 For CA certificates, subject key identifiers SHOULD be derived fro= m the > public key or a method that generates unique values.=A0 Two common method= s for > generating key identifiers from the public key are: > ... > Other methods of generating unique numbers are also acceptable. > So, use of another one-way hash function, e.g., SHA-256 meets the criteri= a > defined above (associated with the "SHOULD") and is consistent with the > final comment. > CAs need to know which function to use, but RPs just perform comparisons.= We > could modify the RPKI cert profile (if Geoff and the SIDR WG don't mind) = to > specify use of SHA-256 for generation of SKI/AKI values. I guess the real > issue is whether commonly used software (e.g., OpenSSL) will support this= . > Steve From pcain@coopercain.com Mon May 17 14:28:21 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432B73A6A15; Mon, 17 May 2010 14:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxJOAFd3Zm+N; Mon, 17 May 2010 14:28:20 -0700 (PDT) Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id B23603A6AEE; Mon, 17 May 2010 14:28:01 -0700 (PDT) Received: from familyroom (familyroom8.bc.edu [136.167.27.76]) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id o4HLRf1w022812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 May 2010 16:27:47 -0500 Received: from familyroom by familyroom (PGP Universal service); Mon, 17 May 2010 17:27:47 -0500 X-PGP-Universal: processed; by familyroom on Mon, 17 May 2010 17:27:47 -0500 From: "Patrick Cain" To: "'Sean Turner'" , "'Roque Gagliano'" References: <020001caeebe$ffdcd560$ff968020$@com> <4BF1580C.70407@ieca.com> In-Reply-To: <4BF1580C.70407@ieca.com> Date: Mon, 17 May 2010 17:27:40 -0400 Message-ID: <02d901caf607$cb1d9d00$6158d700$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr10IGckDeyKMytR1ud5qf7t2OMUQANo2Aw Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us Cc: iesg@ietf.org, draft-ietf-csi-send-name-type-registry.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 21:28:21 -0000 Sean, I'm not so sure that I was *asking* for it, as much as *pointing it out*. Roque, The additional numbers look just fine to me, but I am far from an expert in their use. Pat -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Monday, May 17, 2010 10:52 AM To: Roque Gagliano Cc: Stephen Kent; Patrick Cain; secdir@ietf.org; iesg@ietf.org; draft-ietf-csi-send-name-type-registry.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03 That is what, I believe, Pat was asking for. spt Roque Gagliano wrote: > Stephen/ Patrick/Sean, > > Thank you for your comments. What about adding the following extra > numbers to the registry?: > > +---------+----------------------------------------------------+ > | Value | Description | > +---------+----------------------------------------------------+ > | 0 | Reserved | > | | | > | 1 | DER Encoded X.501 Name (RFC 3971) | > | | | > | 2 | FQDN (RFC 3971) | > | | | > | 3 | SHA-1 Subject Key Identifier (SKI) ( Section 3 ) | > | | | > | 4 | SHA-224 Subject Key Identifier (SKI) ( Section 3 ) | > | | | > | 5 | SHA-256 Subject Key Identifier (SKI) ( Section 3 ) | > | | | > | 6 | SHA-384 Subject Key Identifier (SKI) ( Section 3 ) | > | | | > | 7 | SHA-512 Subject Key Identifier (SKI) ( Section 3 ) | > | | | > | 253-254 | Experimental use | > | | | > | 255 | Reserved | > +---------+----------------------------------------------------+ > > This way we stay ready if SIDR certs uses some of these hashes > functions in the future. > > regards, > > Roque > > > On Wed, May 12, 2010 at 8:00 PM, Stephen Kent wrote: >> At 6:38 PM +0200 5/8/10, Roque Gagliano wrote: >> >> Patrick, >> >> Thank you for your review. >> >> You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and >> required in draft-ietf-sidr-res-cert >> >> Regards, >> >> Roque >> >> Roque, >> 5280 defines how to use SHA-1, but it does not require use of this specific >> hash function. 4.2.1.2 says: >> For CA certificates, subject key identifiers SHOULD be derived from the >> public key or a method that generates unique values. Two common methods for >> generating key identifiers from the public key are: >> ... >> Other methods of generating unique numbers are also acceptable. >> So, use of another one-way hash function, e.g., SHA-256 meets the criteria >> defined above (associated with the "SHOULD") and is consistent with the >> final comment. >> CAs need to know which function to use, but RPs just perform comparisons. We >> could modify the RPKI cert profile (if Geoff and the SIDR WG don't mind) to >> specify use of SHA-256 for generation of SKI/AKI values. I guess the real >> issue is whether commonly used software (e.g., OpenSSL) will support this. >> Steve > From shanna@juniper.net Mon May 17 18:16:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46D63A6BAF; Mon, 17 May 2010 18:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJinXI5kDz9r; Mon, 17 May 2010 18:16:24 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id EACA33A6B9F; Mon, 17 May 2010 18:16:18 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKS/HqWlnimyh7LS3AfuqinZb8YmvyjIlf@postini.com; Mon, 17 May 2010 18:16:17 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 17 May 2010 18:13:05 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 17 May 2010 21:13:05 -0400 From: Stephen Hanna To: "draft-ietf-syslog-dtls.all@tools.ietf.org" Date: Mon, 17 May 2010 21:13:04 -0400 Thread-Topic: secdir review of draft-ietf-syslog-dtls-05 Thread-Index: Acr2J0QrBBRM3O3BS1mHJs7cRimnGQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: [secdir] secdir review of draft-ietf-syslog-dtls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 01:16:25 -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 comments. This document defines a DTLS transport for syslog. The document is well-written, clear, and seems to serve a worthwhile purpose. Although the security considerations section is brief (mainly just referring to the security considerations in RFC 5425, RFC 5246, and RFC 4347), it is largely adequate. I see only one omission. One difference between the security considerations for syslog over DTLS and those for syslog over TLS (unnoted in the current Security Considerations section) is that DTLS does not provide retransmission. If an attacker can cause a packet to be dropped (especially one carrying significant information about an attack), the transport receiver may not consider this a significant event and so the syslog server may be completely unaware of the occurrence. This contrasts with syslog over TLS where a dropped packet would be retransmitted until acknowledged or until the TLS connection goes down (indicating to the transport sender and receiver and perhaps to the syslog client and server that a significant event has occurred). Maybe it would be a good idea to recommend that the transport receiver notice gaps in the DTLS sequence numbers and notify the syslog server. Still, this is not as good from a security standpoint as syslog over TLS since none of the client code will be aware that the dropped message was not received. At least, there should be a discussion of this issue in the Security Considerations section of this document. In addition to this concern, I have noticed a few areas that could use some clarification and maybe some fixes. Section 5.3 says "Implementations MUST support the denial of service countermeasures defined by DTLS." That's good but it's not clear whether this means that these countermeasures MUST always be enabled. Since that is not explicitly stated, it seems that a server could have those countermeasures enabled by default and a client could have them disabled by default. That would result in a client and server that would not interoperate until the administrator tracked down the problem and changed their configuration. I suggest that the document be changed to require not only that implementations support these countermeasures but that they be enabled by default. Section 7 says "The security policies for syslog over DTLS are the same as those described in [RFC5425]." Does that mean that all the normative text in section 5 of RFC 5425 applies to implementations of this document as well? I hope so but if that's the intent, it should be explicitly stated (for example by adding the text "and all the normative requirements of section 5 of [RFC5425] apply"). Once these issues are addressed, I'm sure that the document will be a worthwhile and relatively secure addition to the RFC series. Congratulations and thanks to the editors/authors for their work. Thanks, Steve From phoyer@actividentity.com Tue May 18 06:17:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEC73A698C; Tue, 18 May 2010 06:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.409 X-Spam-Level: X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfIsq8URNeF5; Tue, 18 May 2010 06:17:57 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [92.103.229.143]) by core3.amsl.com (Postfix) with ESMTP id 224DF3A69A0; Tue, 18 May 2010 06:15:06 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id BDCFF18393A; Tue, 18 May 2010 15:14:57 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 18 May 2010 15:17:50 +0200 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4068908EB@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <4BF115AD.5010400@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SecDir review of draft-ietf-keyprov-pskc-05 Thread-Index: Acr1qVnRMyhx+GMiSp++tqcZPZHluQA4xe/A References: <4BDF2F06.2030406@inrialpes.fr> <5BFE9E473DBFC24CA87F18F29B3F0AC406890884@sur-corp-ex-02.corp.ad.activcard.com> <4BF115AD.5010400@inrialpes.fr> From: "Philip Hoyer" To: "Vincent Roca" X-Mailman-Approved-At: Tue, 18 May 2010 06:32:05 -0700 Cc: draft-ietf-keyprov-pskc.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-keyprov-pskc-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 13:17:57 -0000 Vincent, I have changed the draft to encompass your revised wording of point 2 below. Thanks for your help, Philip -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inrialpes.fr]=20 Sent: Monday, May 17, 2010 11:09 AM To: Philip Hoyer Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-keyprov-pskc.all@tools.ietf.org; vincent.roca@inrialpes.fr Subject: Re: SecDir review of draft-ietf-keyprov-pskc-05 Hello Philip, I see we agree on most items (I removed them). Two comments: > 5- section 13.1: > why isn't the IPsec/ESP not considered also as a third > solution to provide the confidentiality, integrity and sender > authentication services? Why do the authors only focus > on PCKS integrated or TLS solutions? It's not clear. > [PH] the authors felt that the usage of the container was intended for > application level interchange of keys. Especially in online scenarios > where TLS is much more prevalent than IPSec. This does not mean that one > could not envisage use of the PSKC over IPsec and hence use IPsec > protection mechanisms. > =20 [VR] I understand. Thanks for the clarification. > 9- section 13.3: it is said: > "A weaker payload authenticity guarantee may be provided by the > transport layer if it is configured to digest each message it > transports." > > Why is this feature necessarily weaker? The source can be > authenticated with the same level of security as if it was > done by the recipient end. > [PH] it is weaker in the sense that the TLS endpoints could differ from > the key provisioning endpoints. So in that sense the signature in the > message would protect it from message sender to receiver. > =20 [VR] Said this way, I fully agree. I suggest you clarify the I-D as well, e.g.: "Authenticity guarantee may be provided by [...]. However, no authenticity verification is possible once [...]. Since the TLS endpoints could=20 differ from the key provisioning endpoints, this solution is weaker than the previous solution that relies on a digital signature of the PSKC." Cheers, Vincent From tlyu@mit.edu Tue May 18 15:06:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF69B3A69BD; Tue, 18 May 2010 15:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=1.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHXiqR2-q3Uq; Tue, 18 May 2010 15:06:12 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id C8C593A68F9; Tue, 18 May 2010 15:06:11 -0700 (PDT) X-AuditID: 12074423-b7c0bae0000030f0-d7-4bf30f4b7601 Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id 49.E7.12528.B4F03FB4; Tue, 18 May 2010 18:06:03 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o4IM627m029996; Tue, 18 May 2010 18:06:03 -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.6/8.12.4) with ESMTP id o4IM60Vq019291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 May 2010 18:06:01 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o4IM5xuF018333; Tue, 18 May 2010 18:05:59 -0400 (EDT) To: secdir@ietf.org, iesg@ietf.org, avt-chairs@tools.ietf.org, draft-ietf-avt-rtcp-guidelines.all@tools.ietf.org From: Tom Yu Date: Tue, 18 May 2010 18:05:58 -0400 Message-ID: Lines: 9 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Subject: [secdir] review of draft-ietf-avt-rtcp-guidelines-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 22:06:12 -0000 draft-ietf-avt-rtcp-guidelines-04 provides guidelines for extending the RTP Control Protocol (RTCP) if its existing capabilities are insufficient for some purpose. The guidelines seem good, and many of them are applicable to network protocol and extension design in general. The Security Considerations section contains a reasonable collection of advice to designers of RTCP extensions regarding the potential security impact of new extensions. From rbarnes@bbn.com Tue May 18 17:37:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB363A6A62; Tue, 18 May 2010 17:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlyqDSbbibv0; Tue, 18 May 2010 17:37:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 57BFD3A69FE; Tue, 18 May 2010 17:37:28 -0700 (PDT) Received: from [192.1.255.188] (port=62609 helo=col-dhcp-192-1-255-188.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OEXHk-0002MQ-EF; Tue, 18 May 2010 20:37:20 -0400 Message-Id: <00CEF527-9674-47CF-BC3E-66A9FC7289F7@bbn.com> From: Richard Barnes To: secdir@ietf.org, iesg@ietf.org, The IETF Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 May 2010 20:37:19 -0400 X-Mailer: Apple Mail (2.936) Cc: draft-ietf-csi-send-cert@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-csi-send-cert-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 00:37: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 a certificate profile for use in the Secure Neighbor Discovery protocol for IPv6. Starting from the RPKI cert profile, it adds some refinements for SEND, e.g., EKUs that authorize the subject to act in certain roles within SEND (router, proxy, host). Overall, the document is reasonably well-written, but could benefit from more precision in its use of terminology. There are a few points (noted below) where certificate processing rules are unclear. With regard to the security considerations in particular, I would prefer if they stated the risks slightly more directly (text is suggested below), but in general, the authors address the major security concerns. Detailed comments follow. --Richard Sec 2 Para 1 Suggest changing "authority over an" to "authorization to advertise an". Sec 2 Para 2 Suggest rewording to avoid referring to SIDR WG (which is temporary). Suggested text: "The Resource Public Key Infrastructure (RPKI) is the global PKI that attests to allocation of IP address space." Also, instead of "SIDR certificate profile", use "RPKI certificate profile". Sec 2 Para 3, General I'm confused by the several instances of the phrase "address owner" in the document (the phrase is not used in RFC 3971). Do you mean "host"? Sec 3 Para "End Entity" This definition is incorrect. Refer to RFC 4949. Sec 4 Para 1 The RPKI profile should be applied in *addition* to the RFC 3971 profile, right? Please clarify. Sec 4 Para 2 Why can there only be one RFC 3779 extensions? It doesn't seem like there's a risk in including IPv4 space (e.g., for a dual-stack router that was vouching for IPv4 space in some other application?), or multiple extensions for IPv6 space. Sec 5 This section should note that another deployment model (arguably the most likely) is a combination of these two, in which most resources are certified under the global RPKI, while some (e.g., ULAs) are certified under local TAs. Sec 6 Para 4 The requirement for RFC 3779 extension seems to contradict the use of ETAs as Trust Anchor Material, i.e., the last sentence of the first paragraph in this section. Sec 7 Para "The inclusion of ..." et seq. It would be helpful for the document to specify how prefix matching should be done when validating these extensions. Which of the following should the RP use? -- Exact matching -- Subset matching (RA within cert) -- The weird subset/intersection algorithm that RFC 3971 defines What prefix should the RP be matching against from SEND, per EKU? E.g., for id-kp-sendRouter, the RFC 3779 extension in the cert should match against any RAs the router emits. It may be useful to refer to the ROA validation document [draft-ietf-sidr-roa-validation]. Sec 7 Para "Certificate-using applications..." Suggest changing "Certificate-using applications" to "Relying Parties". Sec 8 This section correctly identifies the main risk with these extensions (namely, issuance of certs with incorrect roles assigned), but it would be helpful to clarify the application-level impact of these bad issuances. Suggested text: " Since a SEND certificate attest that its subject is authorized to play a given role in the SEND protocol, certificates that contain incorrect EKU values can enable some of the same attacks that SEND was meant to prevent. For example, if a malicious host can obtain a certificate that authorizes it to act as a router for a given prefix, then it can masquerade as a router for that prefix, e.g., in order to attract traffic from local nodes. " From d3e3e3@gmail.com Wed May 19 21:25:22 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6308A3A67F0; Wed, 19 May 2010 21:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+fk9AEmjV89; Wed, 19 May 2010 21:25:21 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C63053A6C59; Wed, 19 May 2010 21:25:20 -0700 (PDT) Received: by wwb24 with SMTP id 24so1224959wwb.31 for ; Wed, 19 May 2010 21:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=pdHqB4e/93TDU3iPPHS1eFhDALU2/2zzlijdvyaBI3A=; b=Q1qnrtji4v/CojdZO5ekxuw9dwTyoTN53ObESeQyngGoyGCA8Ta1C2UxG+vBDtQXf+ Zcv9kLNITh75XClUR3MC7G+KtrcOeiWWmiPlHStO678QmdWlsCzKu/uW12cWIae4JTcb U51I3iHB6LseMZziZTyejzGoQ2B3TU8wH5r5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=YrwGp6LP1jOTj/CxrVbXgAM43G9NYuFr2NMWFNp6uJRG8YX4efHgb2X5O/9BHJqakM fEDwlXf7qdgKfb0/wi7xv2P3qnfa6uKYE0YAKRTnr0KgTATQN64Lm0Wu6O9gBYI3ijVU Crp9SGTPjHYsWDouarW305y5YF21Uz0h4cqqE= MIME-Version: 1.0 Received: by 10.216.89.20 with SMTP id b20mr3332224wef.58.1274329510198; Wed, 19 May 2010 21:25:10 -0700 (PDT) Received: by 10.216.229.210 with HTTP; Wed, 19 May 2010 21:25:10 -0700 (PDT) Date: Thu, 20 May 2010 00:25:10 -0400 Message-ID: From: Donald Eastlake To: iesg@ietf.org, secdir@ietf.org, gerardog@qualcomm.com Content-Type: multipart/alternative; boundary=0016e6d784e8c83ffc0486fef522 Cc: Jonne Soininen Subject: [secdir] draft-ietf-netlmm-mip-interactions-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 04:25:22 -0000 --0016e6d784e8c83ffc0486fef522 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. Document editors and WG chairs should treat these comments just like any other last call comments. This is an Informational draft discussing various IPv6 mobility scenarios that involve interactions between MIPv6 and Proxy MIPv6 (PMIPv6). For security considerations, the draft refers to the comprehensive Security Considerations section of RFC 3775 (Mobility Support in IPv6) and to RFC 4832 (Security Threats to Network-Based Localized Mobility Managemen). I am not an expert in this area and found the shear amount of detail in this draft, which was produced by merging 4 different earlier drafts, somewhat confusing. However, it looks to me like the referenced security considerations sections and the discussions in the draft cover security adequately. Typos/Grammer: Section 3, second sentence: OLD This document does not ^^^^ only focus on scenarios where the two protocols are used by the same mobile node to manage local and global mobility, but it investigates ^^ also more complex scenarios where the protocols are more tightly ^^^^ NEW This document not only focuses on scenarios where the two protocols are used by the same mobile node to manage local and global mobility, but also investigates more complex scenarios where the protocols are more tightly Section 3, page 9, line 4: OLD depicted in the figure. However, the LMA and HA can be also ^^^^^^^ NEW depicted in the figure. However, the LMA and HA can also be Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street +1-508-634-2066 (home) Milford, MA 01757 USA d3e3e3@gmail.com * --0016e6d784e8c83ffc0486fef522 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the securit= y directorate's=A0
ongoing effort to review all IETF document= s being processed by the=A0
IESG. Document editors and WG chairs should treat these comments
=
just like any other last call comments.

This = is an Informational draft discussing various IPv6 mobility
scenar= ios that involve interactions between MIPv6 and Proxy MIPv6
(PMIPv6). For security considerations, the draft refers to the
comprehensive Security Considerations section of RFC 3775 (Mobility
Support in IPv6) and to RFC 4832 (Security Threats to Network-Based
Localized Mobility Managemen). I am not an expert in this area and
found the shear amount of detail in this draft, which was produced b= y
merging 4 different earlier drafts, somewhat confusing. However= , it
looks to me like the referenced security considerations sections and
the discussions in the draft cover security adequately.
=

Typos/Grammer:

Secti= on 3, second sentence:
OLD
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This document does not
= =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^
=A0=A0 only = focus on scenarios where the two protocols are used by the same
=A0=A0 mobile node to manage local and global mobility, but it investi= gates
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^
=A0=A0 = also more complex scenarios where the protocols are more tightly
=A0=A0 ^^^^
NEW
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This docume= nt not
=A0=A0 only focuses on scenarios where the two protocols a= re used by the same
=A0=A0 mobile node to manage local and global= mobility, but also investigates
=A0=A0 more complex scenarios where the protocols are more tightly


Section 3, page 9, line 4:
O= LD
=A0=A0 depicted in the figure. =A0However, the LMA and HA can = be also
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^
NEW
=A0=A0 depicted in the figure. =A0However, the LMA and HA can also be


Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd =A0 +1-508-333-2270 (ce= ll)
155 Beaver Street =A0 +1-508-634-2066 (home)
Milfor= d, MA 01757 USA
 --0016e6d784e8c83ffc0486fef522-- From jari.arkko@piuha.net Wed May 19 22:11:03 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D423A6C96; Wed, 19 May 2010 22:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[AWL=-1.448, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ddNVLNUydiv; Wed, 19 May 2010 22:10:54 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 67C193A6C8F; Wed, 19 May 2010 22:10:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 60F7A2CEB5; Thu, 20 May 2010 08:10:37 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pCdESXZaF2Q; Thu, 20 May 2010 08:10:36 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A560C2CD07; Thu, 20 May 2010 08:10:36 +0300 (EEST) Message-ID: <4BF4C44B.9010806@piuha.net> Date: Thu, 20 May 2010 08:10:35 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Donald Eastlake References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gerardog@qualcomm.com, Jonne Soininen , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-netlmm-mip-interactions-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 05:11:04 -0000 Donald,

Thanks for your review.

Jari

Donald Eastlake kirjoitti:
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG. Document editors and WG chairs should treat these comments
just like any other last call comments.

This is an Informational draft discussing various IPv6 mobility
scenarios that involve interactions between MIPv6 and Proxy MIPv6
(PMIPv6). For security considerations, the draft refers to the
comprehensive Security Considerations section of RFC 3775 (Mobility
Support in IPv6) and to RFC 4832 (Security Threats to Network-Based
Localized Mobility Managemen). I am not an expert in this area and
found the shear amount of detail in this draft, which was produced by
merging 4 different earlier drafts, somewhat confusing. However, it
looks to me like the referenced security considerations sections and
the discussions in the draft cover security adequately.


Typos/Grammer:

Section 3, second sentence:
OLD
                                               This document does not
                                                             ^^^^
   only focus on scenarios where the two protocols are used by the same
   mobile node to manage local and global mobility, but it investigates
                                                        ^^
   also more complex scenarios where the protocols are more tightly
   ^^^^
NEW
                                                This document not
   only focuses on scenarios where the two protocols are used by the same
   mobile node to manage local and global mobility, but also investigates
   more complex scenarios where the protocols are more tightly


Section 3, page 9, line 4:
OLD
   depicted in the figure.  However, the LMA and HA can be also
                                                        ^^^^^^^
NEW
   depicted in the figure.  However, the LMA and HA can also be


Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street   +1-508-634-2066 (home)
Milford, MA 01757 USA

From Nicolas.Williams@oracle.com Thu May 20 10:24:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04D93A6965 for ; Thu, 20 May 2010 10:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZY6sqAAHGj2 for ; Thu, 20 May 2010 10:24:55 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id B268A3A699A for ; Thu, 20 May 2010 10:23:47 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KHNM8g031942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 May 2010 17:23:23 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KDhE1X013077; Thu, 20 May 2010 17:23:20 GMT Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 254758111274376197; Thu, 20 May 2010 10:23:17 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 10:23:15 -0700 Date: Thu, 20 May 2010 12:23:11 -0500 From: Nicolas Williams To: secdir@ietf.org Message-ID: <20100520172310.GQ9605@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090202.4BF5700E.0123:SCFMA4539811,ss=1,fgs=0 Cc: jjaeggli@checkpoint.com, manav.bhatia@alcatel-lucent.com, vishwas@ipinfusion.com, shares@nexthop.com Subject: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 17:24:56 -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. Document editors and WG chairs should treat these comments just like any other last call comments. This document aims to be an Informational RFC describing security problems with various routing protocols. Aside from various spelling and other nits that the RFC-Editor can easily handle, I have no issues with this document and it is ready for publication. Nico -- From weiler+secdir@watson.org Sat May 22 16:37:03 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA873A68C4 for ; Sat, 22 May 2010 16:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXswrb4uAtah for ; Sat, 22 May 2010 16:37:03 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id C15EA3A68BD for ; Sat, 22 May 2010 16:37:02 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o4MNasG9073401 for ; Sat, 22 May 2010 19:36:54 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o4MNassV073398 for ; Sat, 22 May 2010 19:36:54 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 22 May 2010 19:36:54 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 22 May 2010 19:36:54 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 22 May 2010 23:37:04 -0000 Charlie Kaufman is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-06-03 Jeffrey Hutzelman T 2010-06-01 draft-ietf-nsis-ntlp-sctp-12 Barry Leiba TR2010-06-01 draft-moriarty-post-inch-rid-transport-02 Tom Yu TR2010-06-01 draft-krishnan-v6ops-teredo-update-07 Larry Zhu T 2010-06-01 draft-santoni-media-type-tsd-00 For telechat 2010-06-17 Stephen Farrell T 2010-06-15 draft-kucherawy-authres-header-b-01 Last calls and special requests: Rob Austein 2010-05-14 draft-ietf-bmwg-protection-term-08 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-05 Alan DeKok 2010-05-12 draft-ietf-netconf-monitoring-12 Shawn Emery 2010-05-17 draft-ietf-mboned-ipv4-uni-based-mcast-06 Tobias Gondrom 2010-05-11 draft-ietf-tsvwg-dtls-for-sctp-05 Sam Hartman 2010-05-27 draft-ietf-avt-srtp-not-mandatory-05 Paul Hoffman 2010-05-26 draft-ietf-avt-rapid-rtp-sync-10 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Love Hornquist-Astrand 2010-05-31 draft-ietf-ipsecme-eap-mutual-02 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows 2010-05-04 draft-ietf-tsvwg-dtls-for-sctp-05 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Sam Weiler 2010-05-19 draft-hoffman-tls-additional-random-ext-01 Brian Weis 2010-05-19 draft-sheffer-emu-eap-eke-06 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 From new-work-bounces@ietf.org Tue May 25 10:00:06 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E883A710A; Tue, 25 May 2010 10:00:06 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DDD4F3A6C89; Tue, 25 May 2010 10:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100525170001.DDD4F3A6C89@core3.amsl.com> Date: Tue, 25 May 2010 10:00:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 25 May 2010 11:45:30 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Email Address Internationalization (eai) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 17:00:06 -0000 A modified charter has been submitted for the Email Address Internationalization (eai) working group in the Applications Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 1, 2010. Email Address Internationalization (eai) ------------------------------------- Last updated: 2010-05-21 Current Status: Active Chairs: John Klensin Joseph Yee Secretary: Jiankang Yao Applications Area Directors: Alexey Melnikov Peter Saint-Andre Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: ima@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ima Archive: http://www.ietf.org/mail-archive/web/ima Description of Working Group: The email address has two parts, local part and domain part. Email address internationalization must deal with both. This working group's previous experimental efforts investigated the use of UTF-8 as a general approach to email internationalization. That approach is based on the use of an SMTP extension to enable the use of UTF-8 in envelope address local-parts, optionally in address domain-parts, and in mail headers. The mail header contexts can include both addresses and wherever existing protocols (e.g., RFC 2231) permit the use of encoded-words. All WG deliverables specified under the original charter, particularly the experimental protocol specifications, have been completed. The core specifications have been implemented and interoperability tests performed. The WG is now being rechartered to permit advancing revised versions of those specifications and supporting documents into the standards track. As a result of implementation and testing experience, the WG has concluded to drop the model of in-transit downgrading that was a key part of the original effort. In-transit downgrading approaches simply do not work well enough and predictably enough to be worth the considerable additional complexity that accompanies them. In particular, dropping in-transit downgrading eliminates the need for the first significant change to the syntax of an email address since RFC 821 and 822 were published in 1982. Work will therefore reflect a "no fallback" approach. That approach provides a very minimal transition mechanism, but is consistent with the long-term view that email with invalid addresses or syntax should be rejected, rather than fixed up in transit between submission servers and delivery servers. Discoverable fallback addresses that could be applied before or during message submission or after SMTP "final delivery" may be investigated. The WG may also develop other materials to give advice to implementers or operators. Those efforts may lead to informational documents or best practices recommendations, but are considered independent of the core documents. Work on them will progress only under the condition that it not delay the primary standards track specifications. The WG believes that the lessons learned from implementation and testing and removal of in-transit downgrading as a goal eliminates all major areas of controversy about the core specifications and should permit very rapid progress. Such rapid progress is an explicit goal for the WG; issues resolved in the past will not be revisited unless those who wish to do so can demonstrate data, reasoning, or consequences that were not considered earlier. At the same time, any attempt to significantly extend an established and widely deployed set of protocols may uncover new consequences or side effects that need consideration and evaluation. If faced with a choice between spending time on such new considerations, the WG will favor getting things right over accelerating the schedule. Deliverables The following deliverables are foreseen in this charter. The WG chairs may (re)structure the deliverables into specific documents or document sets as needed. Adding or removing documents other than those listed below as "Required" or "Additional" will require a charter update. Required Documents (these are the "core specifications" referred to elsewhere) * Overview and Framework for Internationalized Email, replacing RFC 4952 (Informational or Proposed Standard at IESG discretion once complete) * UTF-8 SMTP extension specification, replacing RFC 5336 (Proposed Standard) * Header format specification, replacing RFC 5335 (Proposed Standard) * Internationalized DSN specification, replacing RFC 5337 (Proposed Standard) * UTF-8 POP specification, replacing RFC 5721 (Proposed Standard) * UTF-8 IMAP specification, replacing RFC 5738 (Proposed Standard) Additional possible documents suggested. While milestones are listed for most of these documents, they may be dropped by the WG with the consent of the Responsible AD. * Advice for MUA implementors (Informational or BCP) * Advice for EAI deployment (Informational or BCP) * Advice for non-ASCII and ASCII addresses for the same mailbox (Informational or BCP) * Mailinglist (Informational or Standards Track, replacing draft-eai-mailinglist) * Mailto (Proposed Standard, updating draft-duerst-mailto-bis to reflect internationalized addresses) * Protocol extensions for RFC 4409 Submission Servers or configuration advice for the MUA->Submission server interface. Goals and Milestones: Mar 2010 Discussion of Recharter for standards track at IETF 77 (completed) May 2010 New charter approval from IESG Jul 2010 EAI Framework to IESG Sep 2010 Headers to IESG Sep 2010 SMTP to IESG Sep 2010 DSN to IESG Nov 2010 IMAP & POP3 to IESG Dec 2010 Decision about possible changes or comments about Submission Servers. If the decision is to generate a document, the decision will include a schedule. Jan 2011 Advice for non-ASCII & ASCII addresses to IESG Jan 2011 Advice for MUA implementors to IESG Jan 2011 Advice for EAI deployment to IESG Apr 2011 Mailinglist to IESG Apr 2011 Mailto (Proposed Standard) to IESG _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue May 25 10:30:21 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD233A68FA; Tue, 25 May 2010 10:30:20 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 29BA13A63D3; Tue, 25 May 2010 10:30:05 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100525173006.29BA13A63D3@core3.amsl.com> Date: Tue, 25 May 2010 10:30:05 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 25 May 2010 11:45:30 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Sieve Mail Filtering Language (sieve) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 17:30:21 -0000 A modified charter has been submitted for the Sieve Mail Filtering Language (sieve) working group in the Applications Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 1, 2010. Sieve Mail Filtering Language (sieve) ------------------------------------- Current Status: Active Last updated: 2010-05-07 Chairs: Cyrus Daboo Aaron Stone Applications Area Directors: Alexey Melnikov Peter Saint-Andre Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: sieve@ietf.org To Subscribe: sieve-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/sieve/current/maillist.html Description of Working Group: The SIEVE email filtering language is specified in RFC 5228, together with a number of extensions. The SIEVE working group is being re-chartered to: (1) Finish work on existing in-progress Working Group documents: (a) External lists (draft-ietf-sieve-external-lists) (b) Notify SIP (draft-ietf-sieve-notify-sip-message) (c) RegEx (draft-ietf-sieve-regex) (d) Include/multi-script (draft-ietf-sieve-include) (e) Sieve in IMAP (draft-ietf-sieve-imap-sieve) (2) Finalize and publish the following SIEVE extensions as proposed standards: (a) General Auto-reply (draft-george-sieve-autoreply) (b) Notify presence (draft-george-sieve-notify-presence) (c) Vacation time (draft-george-sieve-vacation-time) (d) Convert messages (draft-melnikov-sieve-convert) Additional drafts may be added to this list, but only via a charter revision. There must also be demonstrable willingness in the SIEVE development community to actually implement a given extension before it can be added to this charter. (3) Work on a specification for iCalendar and vCard extraction, and cooperate with the VCARDDAV WG for address book tests in Sieve. (4) Work on a specification to describe how EAI/IDN issues should be handled in SIEVE. (5) Work on a "Benefits of SIEVE" guide for client and server vendors that: (a) Describes the SIEVE protocol and its suite of extensions. (b) Explains the benefits of server-side filtering in practical terms. (c) Shows how client-side filtering can be migrated to SIEVE. (6) Produce one or more informational RFCs containing a set of test scripts and test email messages that are to be filtered by the scripts, and the expected results of that filtering. This will serve as the basis of a interoperability test suite to help determine the suitability of moving the base specification and selected extensions to Draft status. Goals and Milestones: Done - Submit revised variables draft. Done - Submit revised vacation draft. Done - WG last call for variables draft. Done - Initial submission of RFC 3028bis. Done - WG last call for RFC 3028bis. Done - Initial submission of revised relational draft. Done - Initial submission of revised subaddress draft. Done - Initial submission of revised spamtest/virustest draft. Done - Submit revised editheader draft. Done - Submit revised imapflags draft. Done - WG last call of revised subaddress draft. Done - Submit revised body test draft. Done - Submit revised reject before delivery draft. Done - WG last call for editheader draft. Done - WG last call for body test draft. Done - WG last call for refuse draft Done - WG last call of revised spamtest draft Done - Submit variables draft to IESG Done - Submit revised loop draft Done - Submit revised notification action draft Done - WG last call of revised relational draft Done - WG last call for imap-flags draft Done - WG last call for vacation draft Done - WG last call of revised subaddress draft Done - Submit revised relational draft to IESG Done - Submit vacation draft to IESG Done - Submit revised subaddress draft to IESG Done - Submit imapflags draft to IESG Done - Submit revised spamtest draft to IESG Done - Submit 3028bis to IESG Done - Submit editheader draft to IESG Done - Submit body test draft to IESG Done - WG last call for notification action draft Done - Submit notification action draft to IESG Done - Submit refuse-reject to IESG Done - Submit notify-mailto to IESG Done - Submit mime-loops to IESG Done - WGLC iHave Done - WGLC Notary Done - Submit iHave to IESG Done - Submit Notary to IESG Done - WGLC sieve-in-xml Done - Submit sieve-in-xml to IESG Done - WGLC ManageSIEVE Done - Submit ManageSIEVE to IESG Done - WGLC Notify-sip Done - WGLC Metadata Done - Submit Metadata to IESG Done - Publish refuse/reject - RFC 5429 Done - Publish notify base spec - RFC 5435 Done - Publish notify mailto extension - RFC 5436 Done - Publish notify xmpp extension - RFC 5437 Done - Publish ihave - RFC 5463 Done - Publish meta-data - RFC 5490 Done - Publish mime loops - RFC 5703 Done - Publish Sieve in XML - RFC 5784 Done - Revised RegEx draft Apr 2010 - Revised Include/multi-script draft Apr 2010 - WGLC external-lists May 2010 - WGLC Include/multi-script May 2010 - Submit external-lists to IESG Jun 2010 - Submit Include/multi-script to IESG Jun 2010 - WGLC Notify-SIP Jul 2010 - Initial eai-issues draft Jul 2010 - Submit Notify-SIP to IESG Aug 2010 - WGLC RegEx Aug 2010 - Initial test-scripts draft Aug 2010 - Initial benefits draft Sep 2010 - Submit RegEx to IESG Oct 2010 - WGLC eai-issues Nov 2010 - Submit eai-issues to IESG Nov 2010 - WGLC benefits Jan 2011 - Submit benefits to IESG Mar 2011 - WGLC test-scripts Apr 2011 - Submit test-scripts to IESG _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From bew@cisco.com Tue May 25 17:41:42 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8C03A6B46; Tue, 25 May 2010 17:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGe9-zmasrIr; Tue, 25 May 2010 17:41:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0FA233A6E74; Tue, 25 May 2010 16:19:21 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIf3+0urR7H+/2dsb2JhbACeGXGmWZl1hRMEg0I X-IronPort-AV: E=Sophos;i="4.53,300,1272844800"; d="scan'208";a="535195453" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 25 May 2010 23:19:10 +0000 Received: from dhcp-128-107-163-73.cisco.com (dhcp-128-107-163-73.cisco.com [128.107.163.73]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4PNJAvJ018454; Tue, 25 May 2010 23:19:10 GMT Message-Id: <81F9B37E-EDA2-445F-9980-7A468D9172F5@cisco.com> From: Brian Weis To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 May 2010 16:19:04 -0700 X-Mailer: Apple Mail (2.936) Cc: draft-sheffer-emu-eap-eke@tools.ietf.org Subject: [secdir] Secdir review of draft-sheffer-emu-eap-eke-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 00:41:42 -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 describes a new EAP method based on the Encrypted Key Exchange (EKE) protocol. The well-defined EKE exchange is preceded by a new crypto policy negotiation exchange, several of the payloads are protected by authenticated encryption, and a cryptographic confirmation that both the server and peer have seen identical messages has been added. The document and Security Considerations are comprehensive, and I see no issues that need to be addressed. I do have the following suggestions for improvement. Section 3.1. The schematic of the EAP-EKE messages (bottom of page 6) defines a number of terms for the first time, without explanation. The single sentence following it (top of page 7) seems intended to point the reader to Section 5 to find those terms. It ought to be a little more descriptive. At a minimum, I suggest something like "Section 5 explains the various cryptographic values and how they are derived." Section 5.1. The strength of x_s is significantly determined by the choice of randomness method deriving x_s. It seems that a weak source of randomness would be a significant implementation flaw for EAP-EKE. This section does refer to RFC 4086 for randomness recommendations, which should certainly be helpful to implementors. But perhaps also referencing some well-known methods (e.g., NIST SP 800-90) would be even better. Section 7.3. The sentence following the table seems to be trying to define a PRF as something with a "K" and an "S", but doesn't define what those values mean. This should either be clarified, or have the section point to a better external definition of a PRF. Section 7.6. Defining a registry without any standardized values (other than a "reserved" value of 0x0) isn't very useful for interoperability. If the expectation is that private use values will be mainly used, perhaps the channel binding value should be treated as a vendor-id payload rather than a registry. Brian From yaronf.ietf@gmail.com Wed May 26 05:21:36 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F983A6804 for ; Wed, 26 May 2010 05:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anmFOCrL8b4E for ; Wed, 26 May 2010 05:21:34 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 281253A68EB for ; Wed, 26 May 2010 05:21:33 -0700 (PDT) Received: by fxm20 with SMTP id 20so65788fxm.31 for ; Wed, 26 May 2010 05:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=FsmAtGbroxk8JoRGbRPfvgZUQSFx7eR0IehLTtwGeWs=; b=HufBCoqVfunRQuJ4ckjMJEEFAETjScWUBCNskwD5KAjuT40200oATYUw2PXpBg+ZOn /5W0/SRuo1mE1cTJq2KHDaui2eKAVldxR2vs5nfPdlT1F5JIjLspce+ETcQeFSR4rI6t kz7rxowTRf75Vkz+nW20og/JU+1Gq0K9pireU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=IYOuyoijATbYHzh03Kf0AaYX9KDE/S00GvedKkwNpzgaUdkS4/Ajt7NwlYKHhnxeqn RKNt8eBeymaSUAoRZf2yuSImgdH7sGXU6a+dQLnJrXOpK2Hn9KG4QS8Id6fKOtYjFbHa LmLE8Y26/7DROGHPU03VYDAmSdINRmN0JtFDk= Received: by 10.223.33.218 with SMTP id i26mr7563281fad.58.1274876480342; Wed, 26 May 2010 05:21:20 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-180-38-209.red.bezeqint.net [79.180.38.209]) by mx.google.com with ESMTPS id g10sm178543fai.12.2010.05.26.05.21.17 (version=SSLv3 cipher=RC4-MD5); Wed, 26 May 2010 05:21:18 -0700 (PDT) Message-ID: <4BFD123B.6020106@gmail.com> Date: Wed, 26 May 2010 15:21:15 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brian Weis References: <81F9B37E-EDA2-445F-9980-7A468D9172F5@cisco.com> In-Reply-To: <81F9B37E-EDA2-445F-9980-7A468D9172F5@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-sheffer-emu-eap-eke@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 12:21:36 -0000 Hi Brian, thanks for your review. I accept all of your comments, with the exception of the last one: I consider channel binding as an important capability, which implies that it needs to be provided in an interoperable manner. There is no standard set of channel binding properties yet, but I expect that eventually we will have one. http://tools.ietf.org/html/draft-clancy-emu-aaapay-04 presents one viable direction for doing that, and I have asked the authors of that draft to add a section that describes how their proposal can integrate with EAP-EKE. In other words, the Channel Binding Value payload should not be seen as a "vendor ID", but rather as a placeholder for a standardized solution. Thanks, Yaron On 05/26/2010 02:19 AM, Brian Weis 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. > > This document describes a new EAP method based on the Encrypted Key > Exchange (EKE) protocol. The well-defined EKE exchange is preceded by a > new crypto policy negotiation exchange, several of the payloads are > protected by authenticated encryption, and a cryptographic confirmation > that both the server and peer have seen identical messages has been added. > > The document and Security Considerations are comprehensive, and I see no > issues that need to be addressed. I do have the following suggestions > for improvement. > > Section 3.1. The schematic of the EAP-EKE messages (bottom of page 6) > defines a number of terms for the first time, without explanation. The > single sentence following it (top of page 7) seems intended to point the > reader to Section 5 to find those terms. It ought to be a little more > descriptive. At a minimum, I suggest something like "Section 5 explains > the various cryptographic values and how they are derived." > > Section 5.1. The strength of x_s is significantly determined by the > choice of randomness method deriving x_s. It seems that a weak source of > randomness would be a significant implementation flaw for EAP-EKE. This > section does refer to RFC 4086 for randomness recommendations, which > should certainly be helpful to implementors. But perhaps also > referencing some well-known methods (e.g., NIST SP 800-90) would be even > better. > > Section 7.3. The sentence following the table seems to be trying to > define a PRF as something with a "K" and an "S", but doesn't define what > those values mean. This should either be clarified, or have the section > point to a better external definition of a PRF. > > Section 7.6. Defining a registry without any standardized values (other > than a "reserved" value of 0x0) isn't very useful for interoperability. > If the expectation is that private use values will be mainly used, > perhaps the channel binding value should be treated as a vendor-id > payload rather than a registry. > > Brian From turners@ieca.com Wed May 26 06:19:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5711E3A6958 for ; Wed, 26 May 2010 06:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afQXx1WBeZI5 for ; Wed, 26 May 2010 06:19:48 -0700 (PDT) Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 42EDA3A6962 for ; Wed, 26 May 2010 06:19:46 -0700 (PDT) Received: (qmail 51639 invoked from network); 26 May 2010 13:19:34 -0000 Received: from dhcptemp39.cs.columbia.edu (turners@128.59.17.239 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 26 May 2010 06:19:34 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: YXEvTeAVM1khqxrFudEPTcPQqJ851F3NiHePGwQMV0U80l4Dk.fwxkiAEUVLhXDl6heBHIxeo773La2QKpOGtbwiHJIXurEKZwJEvRtKEPTxNnu7XWcmfEkf.d3zG8y5AAveiEMV3Us7nPcw6yyzm_yjyufl7_gEMNh4Ae4rbyMM2fpZtN32S2rY6bQkuUNVxb7wGIJIlEFIA_qhthmZUOeo.uA3h5FeZ5vQLkl4qH93T7AluuhwkNmHHtKb7GWMb58mbnKqcA4sulJtqC7cgZDUdRrvWaBneQ3d6IVQqeubQ8mc4AGvB34qsttcsQ1KZj.YwJPUjxPPN0L5K0zt_Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BFD1FE5.10207@ieca.com> Date: Wed, 26 May 2010 09:19:33 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org, saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] The IETF Security Area Wiki and our new AD blogs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 13:19:48 -0000 While at the IESG retreat, Tim and I decided to update the Security Area wiki, which if you didn't know is located at: http://trac.tools.ietf.org/area/sec/trac/wiki Tim and I also decided to add a blog for each of us, which is going to be eerily similar to monthly AD notes: http://trac.tools.ietf.org/area/sec/trac/wiki/TimsBlog http://trac.tools.ietf.org/area/sec/trac/wiki/SeansBlog I'm hoping that we'll both update on it on a regular basis. spt From yaronf.ietf@gmail.com Wed May 26 08:06:50 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BCCA3A6977 for ; Wed, 26 May 2010 08:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YePFewyV-hF for ; Wed, 26 May 2010 08:06:49 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BA26F3A6976 for ; Wed, 26 May 2010 08:06:48 -0700 (PDT) Received: by fxm20 with SMTP id 20so246926fxm.31 for ; Wed, 26 May 2010 08:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=OPt2HKJM3/JUMd4xrAEtvpSQAhS2tVriUExAP8lmHIY=; b=tjFI+QAXxE67lf2+E1w5gfzYZQt+oZwul1YQthU/xFb2nSr1TG6ZSWQ7mw6BlNpfJ7 5s2+273EVwbboXphfSMR5sgiD2YkSVqJyqCouC/PUzvqeho/wuoBfeq2asAMRbKEkccV PClwuP1SkPOJszOxCrq9nVPzehhcPoMd4daVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=X+HerpGJI7FIp6vRV4rMKI5NtaRgoX7zkvIb2ETuw7/7qyHcGXJGTgkRSCh+9dW66I cRFR9Mrvs2TlM85SfVPeTE81OA4YH7oOiC4fcItqP9UlYZso+JyPDHWrSAEnIyxRStMY JjitJ0bKXpCaukjrfkBvIrk/PDgaRKTdNVbYM= Received: by 10.223.65.73 with SMTP id h9mr7773686fai.75.1274886396597; Wed, 26 May 2010 08:06:36 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-180-38-209.red.bezeqint.net [79.180.38.209]) by mx.google.com with ESMTPS id z12sm803108fah.9.2010.05.26.08.06.34 (version=SSLv3 cipher=RC4-MD5); Wed, 26 May 2010 08:06:35 -0700 (PDT) Message-ID: <4BFD38F9.20800@gmail.com> Date: Wed, 26 May 2010 18:06:33 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Sean Turner References: <4BFD1FE5.10207@ieca.com> In-Reply-To: <4BFD1FE5.10207@ieca.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] [saag] The IETF Security Area Wiki and our new AD blogs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 15:06:50 -0000 Hi Sean, the security AD blog is a very good idea. But (unless I'm missing something) the Trac wiki doesn't support RSS or any other kind of subscription, which makes it much less useful than plain old email. So I hope you are still planning to mail out the AD notes. Thanks, Yaron On 05/26/2010 04:19 PM, Sean Turner wrote: > While at the IESG retreat, Tim and I decided to update the Security Area > wiki, which if you didn't know is located at: > http://trac.tools.ietf.org/area/sec/trac/wiki > > Tim and I also decided to add a blog for each of us, which is going to > be eerily similar to monthly AD notes: > > http://trac.tools.ietf.org/area/sec/trac/wiki/TimsBlog > http://trac.tools.ietf.org/area/sec/trac/wiki/SeansBlog > > I'm hoping that we'll both update on it on a regular basis. > > spt > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From turners@ieca.com Wed May 26 11:03:51 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318323A691A for ; Wed, 26 May 2010 11:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv6DA6Gf4wUY for ; Wed, 26 May 2010 11:03:50 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id 18F6E3A690B for ; Wed, 26 May 2010 11:03:50 -0700 (PDT) Received: (qmail 84411 invoked from network); 26 May 2010 18:03:29 -0000 Received: from dhcptemp39.cs.columbia.edu (turners@128.59.17.239 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 26 May 2010 11:03:28 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: YbiDhl4VM1nIK7.R6Aaaq.kgjhTptUHwZX.cMhk7z3DxbpvXhSLTSaAdCmLKBWyWPpLZEuBIZQS2MQ18EFYXaR4zq9C._522HcQJV31NWeBLlCLq4GSHlV.AcFP073QiER0V4PCsS_apgferwe8mC.GSJ7NL3vIR8YXC0qO2qPajvyYCYaADcViavOGxqoybJRpUiPtPorrq8gU4dzVyGUFk7PI0RrXaZ9kClrZ1k08i7CI5Baum6izj.tAEYNuufXNaDFB1.tPxELR1xj1.C7n3GvmuC1tZiiDtdsn7P8yioSe7cqDUwvBDWl7MF4rd8tlcYdPLK2Pp_5Ca3xTKSw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BFD6270.9060109@ieca.com> Date: Wed, 26 May 2010 14:03:28 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yaron Sheffer References: <4BFD1FE5.10207@ieca.com> <4BFD38F9.20800@gmail.com> In-Reply-To: <4BFD38F9.20800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] [saag] The IETF Security Area Wiki and our new AD blogs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:03:51 -0000 I am going to continue the email. The blog, which is really just a wiki, would match the email. I'm checking to see if they're give me a real blog with RSS. spt Yaron Sheffer wrote: > Hi Sean, > > the security AD blog is a very good idea. But (unless I'm missing > something) the Trac wiki doesn't support RSS or any other kind of > subscription, which makes it much less useful than plain old email. So I > hope you are still planning to mail out the AD notes. > > Thanks, > Yaron > > > On 05/26/2010 04:19 PM, Sean Turner wrote: >> While at the IESG retreat, Tim and I decided to update the Security Area >> wiki, which if you didn't know is located at: >> http://trac.tools.ietf.org/area/sec/trac/wiki >> >> Tim and I also decided to add a blog for each of us, which is going to >> be eerily similar to monthly AD notes: >> >> http://trac.tools.ietf.org/area/sec/trac/wiki/TimsBlog >> http://trac.tools.ietf.org/area/sec/trac/wiki/SeansBlog >> >> I'm hoping that we'll both update on it on a regular basis. >> >> spt >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > From hartmans@mit.edu Thu May 27 11:31:33 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B676A3A6848 for ; Thu, 27 May 2010 11:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0dTtdKkgrnu for ; Thu, 27 May 2010 11:31:33 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 45ED63A690E for ; Thu, 27 May 2010 11:31:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0CF2F201B2; Thu, 27 May 2010 14:31:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0518D43EF; Thu, 27 May 2010 14:30:47 -0400 (EDT) From: Sam Hartman To: Yaron Sheffer References: <81F9B37E-EDA2-445F-9980-7A468D9172F5@cisco.com> <4BFD123B.6020106@gmail.com> Date: Thu, 27 May 2010 14:30:47 -0400 In-Reply-To: <4BFD123B.6020106@gmail.com> (Yaron Sheffer's message of "Wed, 26 May 2010 15:21:15 +0300") 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: draft-sheffer-emu-eap-eke@tools.ietf.org, emu-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 18:31:33 -0000 >>>>> "Yaron" == Yaron Sheffer writes: Yaron> Hi Brian, thanks for your review. I accept all of your Yaron> comments, with the exception of the last one: I consider Yaron> channel binding as an important capability, which implies Yaron> that it needs to be provided in an interoperable Yaron> manner. There is no standard set of channel binding Yaron> properties yet, but I expect that eventually we will have Yaron> one. http://tools.ietf.org/html/draft-clancy-emu-aaapay-04 Yaron> presents one viable direction for doing that, and I have Yaron> asked the authors of that draft to add a section that Yaron> describes how their proposal can integrate with EAP-EKE. In Yaron> other words, the Channel Binding Value payload should not be Yaron> seen as a "vendor ID", but rather as a placeholder for a Yaron> standardized solution. I've agreed to take over editorship of draft-ietf-emu-chbind. My role in this is part of a larger client engagement. Currently, I'm schedule to write up my understanding of some open issues with this document including a discussion I had with Glenn at the last IETF in early June and to get a new draft out by the cutoff. One of the specific discussions that came up was the importance of making sure we have a consistent strategy across EAP methods for including channel binding values. I'll be happy to take a look at EKE when I take a look at other methods for the emu-chbind update. From hartmans@mit.edu Thu May 27 11:48:23 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7F93A68A5 for ; Thu, 27 May 2010 11:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDQLNtTBpQIe for ; Thu, 27 May 2010 11:48:22 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 369CE3A690E for ; Thu, 27 May 2010 11:48:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9D976202FB; Thu, 27 May 2010 14:48:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A5C5443EF; Thu, 27 May 2010 14:47:40 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <20100520172310.GQ9605@oracle.com> Date: Thu, 27 May 2010 14:47:40 -0400 In-Reply-To: <20100520172310.GQ9605@oracle.com> (Nicolas Williams's message of "Thu, 20 May 2010 12:23:11 -0500") 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: shares@nexthop.com, jjaeggli@checkpoint.com, manav.bhatia@alcatel-lucent.com, vishwas@ipinfusion.com, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 18:48:23 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> I have reviewed this document as part of the security Nicolas> directorate's ongoing effort to review all IETF documents Nicolas> being processed by the IESG. Document editors and WG chairs Nicolas> should treat these comments just like any other last call Nicolas> comments. Nicolas> This document aims to be an Informational RFC describing Nicolas> security problems with various routing protocols. Nicolas> Aside from various spelling and other nits that the Nicolas> RFC-Editor can easily handle, I have no issues with this Nicolas> document and it is ready for publication. This document talks a lot about collision attacks against MD5 and then draws the conclusion that MD5 should not be used as part of a MAC. I agree that it is prudent to provide alternatives to MD5. However, I think the current text implies that collision attacks against MD5 are applicable to attacks against the use of MD5 in routing protocols. There is an introductory section that describes the difference between pre image and collision attacks, but the rest of the document seems to ignore the advice of that section. From Sandra.Murphy@cobham.com Thu May 27 11:56:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B9C3A695E for ; Thu, 27 May 2010 11:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdqyrBz41EWD for ; Thu, 27 May 2010 11:56:47 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 7D2A73A692E for ; Thu, 27 May 2010 11:56:47 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o4RIuRmv007887; Thu, 27 May 2010 13:56:27 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o4RIuQIn020425; Thu, 27 May 2010 13:56:26 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.107]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 May 2010 14:56:26 -0400 Date: Thu, 27 May 2010 14:56:26 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Sam Hartman In-Reply-To: Message-ID: References: <20100520172310.GQ9605@oracle.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 May 2010 18:56:26.0182 (UTC) FILETIME=[4EDF2E60:01CAFDCE] Cc: manav.bhatia@alcatel-lucent.com, vishwas@ipinfusion.com, secdir@ietf.org, shares@nexthop.com, jjaeggli@checkpoint.com Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 18:56:48 -0000 I was discussing this just this morning with a colleague. The discussion of pre-image and collision points out that using collisions as an attack on a routing protocol is not that easy since routing protocols have format requirements - the attacker would have to find a collision that is also a validly formatted protocol packet. Even beyond that, if the authors can point to some damage an attacker could do in a routing protocol using a collision, that would be very interesting. --Sandy On Thu, 27 May 2010, Sam Hartman wrote: >>>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> I have reviewed this document as part of the security > Nicolas> directorate's ongoing effort to review all IETF documents > Nicolas> being processed by the IESG. Document editors and WG chairs > Nicolas> should treat these comments just like any other last call > Nicolas> comments. > > Nicolas> This document aims to be an Informational RFC describing > Nicolas> security problems with various routing protocols. > > Nicolas> Aside from various spelling and other nits that the > Nicolas> RFC-Editor can easily handle, I have no issues with this > Nicolas> document and it is ready for publication. > > This document talks a lot about collision attacks against MD5 and then > draws the conclusion that MD5 should not be used as part of a MAC. I > agree that it is prudent to provide alternatives to MD5. However, I > think the current text implies that collision attacks against MD5 are > applicable to attacks against the use of MD5 in routing protocols. > > There is an introductory section that describes the difference between > pre image and collision attacks, but the rest of the document seems to > ignore the advice of that section. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From Nicolas.Williams@oracle.com Thu May 27 12:35:32 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF723A6BB2 for ; Thu, 27 May 2010 12:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.743 X-Spam-Level: X-Spam-Status: No, score=-5.743 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G99ngzKdj51m for ; Thu, 27 May 2010 12:35:32 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 178A13A6C44 for ; Thu, 27 May 2010 12:29:33 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RJSvJA022433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 May 2010 19:28:59 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RHOk9m019304; Thu, 27 May 2010 19:28:56 GMT Received: from abhmt008.oracle.com by acsmt354.oracle.com with ESMTP id 274863411274988535; Thu, 27 May 2010 12:28:55 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 May 2010 12:28:54 -0700 Date: Thu, 27 May 2010 14:28:50 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100527192849.GE9605@oracle.com> References: <20100520172310.GQ9605@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090206.4BFEC7FE.00BF:SCFMA922111,ss=1,fgs=0 Cc: shares@nexthop.com, jjaeggli@checkpoint.com, manav.bhatia@alcatel-lucent.com, vishwas@ipinfusion.com, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 19:35:32 -0000 On Thu, May 27, 2010 at 02:47:40PM -0400, Sam Hartman wrote: > This document talks a lot about collision attacks against MD5 and then > draws the conclusion that MD5 should not be used as part of a MAC. I > agree that it is prudent to provide alternatives to MD5. However, I > think the current text implies that collision attacks against MD5 are > applicable to attacks against the use of MD5 in routing protocols. I noticed this, but decided it was a non-issue for me. The document isn't intended to provide advice, though advice is effectively implied. And as for MD5, I won't be sorry to see it go, whether used as the foundation for a MAC or not. Nico -- From Sandra.Murphy@cobham.com Thu May 27 12:36:04 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2FC13A6DAA for ; Thu, 27 May 2010 12:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id broqHeML8e3y for ; Thu, 27 May 2010 12:36:03 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 328F43A6F7B for ; Thu, 27 May 2010 12:30:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o4RJU4GZ008437; Thu, 27 May 2010 14:30:04 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o4RJU3l4022010; Thu, 27 May 2010 14:30:04 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.107]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 May 2010 15:30:03 -0400 Date: Thu, 27 May 2010 15:30:03 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Vishwas Manral In-Reply-To: <7539F1875DE542E7803619C575355E02@vishwasd520> Message-ID: References: <20100520172310.GQ9605@oracle.com> <7539F1875DE542E7803619C575355E02@vishwasd520> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 May 2010 19:30:03.0400 (UTC) FILETIME=[013A3880:01CAFDD3] Cc: manav.bhatia@alcatel-lucent.com, secdir@ietf.org, shares@nexthop.com, jjaeggli@checkpoint.com, 'Sam Hartman' Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 19:36:04 -0000 On Thu, 27 May 2010, Vishwas Manral wrote: > Hi Sam/ Sandra, > > I agree with what you guys have said, we can work to refine the wording to > make it clear that there are no known attacks. > > There may not be known attacks based on collision, but that does not > preclude future issues that may result. One thing I can see is if we can > change the topology field and still have the right/ same hash, it could lead > to basic issues like traffic redirection, black holes and routing loops. I > agree the fact that the packet needs to be a valid format packet makes the > attack considerably harder. I really did mean what I said - if you can think of cases where routing protocols could be damaged by a collision attack, speak up. Most of the things I could think of were attacks that resulted from a legitimate participant behaving badly, and we all know just how much risk routing protocols face from legitimate participants behaving badly anyway - collisions would be no more risk. --Sandy > > Thanks, > Vishwas > > -----Original Message----- > From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] > Sent: Thursday, May 27, 2010 11:56 AM > To: Sam Hartman > Cc: Nicolas Williams; shares@nexthop.com; jjaeggli@checkpoint.com; > manav.bhatia@alcatel-lucent.com; vishwas@ipinfusion.com; secdir@ietf.org > Subject: Re: [secdir] Review of > draft-ietf-opsec-routing-protocols-crypto-issues-04 > > I was discussing this just this morning with a colleague. > > The discussion of pre-image and collision points out that using collisions > as an attack on a routing protocol is not that easy since routing > protocols have format requirements - the attacker would have to find a > collision that is also a validly formatted protocol packet. > > Even beyond that, if the authors can point to some damage an attacker > could do in a routing protocol using a collision, that would be very > interesting. > > > --Sandy > > On Thu, 27 May 2010, Sam Hartman wrote: > >>>>>>> "Nicolas" == Nicolas Williams writes: >> >> Nicolas> I have reviewed this document as part of the security >> Nicolas> directorate's ongoing effort to review all IETF documents >> Nicolas> being processed by the IESG. Document editors and WG chairs >> Nicolas> should treat these comments just like any other last call >> Nicolas> comments. >> >> Nicolas> This document aims to be an Informational RFC describing >> Nicolas> security problems with various routing protocols. >> >> Nicolas> Aside from various spelling and other nits that the >> Nicolas> RFC-Editor can easily handle, I have no issues with this >> Nicolas> document and it is ready for publication. >> >> This document talks a lot about collision attacks against MD5 and then >> draws the conclusion that MD5 should not be used as part of a MAC. I >> agree that it is prudent to provide alternatives to MD5. However, I >> think the current text implies that collision attacks against MD5 are >> applicable to attacks against the use of MD5 in routing protocols. >> >> There is an introductory section that describes the difference between >> pre image and collision attacks, but the rest of the document seems to >> ignore the advice of that section. >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> > > From Sandra.Murphy@cobham.com Thu May 27 12:38:39 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6175C3A69A9 for ; Thu, 27 May 2010 12:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ja+mCkErO7Q for ; Thu, 27 May 2010 12:38:38 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8C8BD3A6C14 for ; Thu, 27 May 2010 12:34:56 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o4RJYcbm008489; Thu, 27 May 2010 14:34:38 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o4RJYcfA022164; Thu, 27 May 2010 14:34:38 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.107]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 May 2010 15:34:37 -0400 Date: Thu, 27 May 2010 15:34:37 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Vishwas Manral In-Reply-To: <79A9D5F8D7F34387A9D07D99A7772BC5@vishwasd520> Message-ID: References: <20100520172310.GQ9605@oracle.com> <79A9D5F8D7F34387A9D07D99A7772BC5@vishwasd520> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 May 2010 19:34:37.0088 (UTC) FILETIME=[A45BB200:01CAFDD3] Cc: manav.bhatia@alcatel-lucent.com, secdir@ietf.org, shares@nexthop.com, jjaeggli@checkpoint.com, 'Sam Hartman' Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 19:38:39 -0000 On Thu, 27 May 2010, Vishwas Manral wrote: > Hi Sandra, > > You may look at the draft I have added below (which I sent to the list but > never posted) > > http://www.ietf.org/mail-archive/web/saag/current/msg01732.html > > It talks about the fact that there is another (like in your case a validly > formatted protocol packet) check which can greatly reduce the effect of > collision. > > Do let me know what you think about the same with respect to the draft at > hand? Well, until we figure out that a collision would lead to bad things happening, there's no real need to make a check to reduce the chance of a collision. Which is why I asked. There's a general concern that MD5 is showing weakness and so we're all happy to see movement away from MD5. But the collision risk at the moment is not clear. --Sandy > > Thanks, > Vishwas > -----Original Message----- > From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] > Sent: Thursday, May 27, 2010 11:56 AM > To: Sam Hartman > Cc: Nicolas Williams; shares@nexthop.com; jjaeggli@checkpoint.com; > manav.bhatia@alcatel-lucent.com; vishwas@ipinfusion.com; secdir@ietf.org > Subject: Re: [secdir] Review of > draft-ietf-opsec-routing-protocols-crypto-issues-04 > > I was discussing this just this morning with a colleague. > > The discussion of pre-image and collision points out that using collisions > as an attack on a routing protocol is not that easy since routing > protocols have format requirements - the attacker would have to find a > collision that is also a validly formatted protocol packet. > > Even beyond that, if the authors can point to some damage an attacker > could do in a routing protocol using a collision, that would be very > interesting. > > > --Sandy > > On Thu, 27 May 2010, Sam Hartman wrote: > >>>>>>> "Nicolas" == Nicolas Williams writes: >> >> Nicolas> I have reviewed this document as part of the security >> Nicolas> directorate's ongoing effort to review all IETF documents >> Nicolas> being processed by the IESG. Document editors and WG chairs >> Nicolas> should treat these comments just like any other last call >> Nicolas> comments. >> >> Nicolas> This document aims to be an Informational RFC describing >> Nicolas> security problems with various routing protocols. >> >> Nicolas> Aside from various spelling and other nits that the >> Nicolas> RFC-Editor can easily handle, I have no issues with this >> Nicolas> document and it is ready for publication. >> >> This document talks a lot about collision attacks against MD5 and then >> draws the conclusion that MD5 should not be used as part of a MAC. I >> agree that it is prudent to provide alternatives to MD5. However, I >> think the current text implies that collision attacks against MD5 are >> applicable to attacks against the use of MD5 in routing protocols. >> >> There is an introductory section that describes the difference between >> pre image and collision attacks, but the rest of the document seems to >> ignore the advice of that section. >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> > > From Nicolas.Williams@oracle.com Thu May 27 12:40:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A8A3A692E for ; Thu, 27 May 2010 12:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bze876B7g+7k for ; Thu, 27 May 2010 12:40:57 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5FE4E3A6987 for ; Thu, 27 May 2010 12:40:22 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RJdxEf015112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 May 2010 19:40:02 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RIJu6I025165; Thu, 27 May 2010 19:39:57 GMT Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 303674181274989087; Thu, 27 May 2010 12:38:07 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 May 2010 12:38:06 -0700 Date: Thu, 27 May 2010 14:38:02 -0500 From: Nicolas Williams To: Sandra Murphy Message-ID: <20100527193801.GF9605@oracle.com> References: <20100520172310.GQ9605@oracle.com> <7539F1875DE542E7803619C575355E02@vishwasd520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090202.4BFECA94.00D6:SCFMA4539811,ss=1,fgs=0 Cc: manav.bhatia@alcatel-lucent.com, Vishwas Manral , secdir@ietf.org, shares@nexthop.com, jjaeggli@checkpoint.com, 'Sam Hartman' Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 19:40:57 -0000 On Thu, May 27, 2010 at 03:30:03PM -0400, Sandra Murphy wrote: > I really did mean what I said - if you can think of cases where > routing protocols could be damaged by a collision attack, speak up. I'd rather not bother because I'd rather be conservative in the design of new protocols and fixes to existing ones. Provide for key exchange, PSK and/or PK authenticatoin methods and use modern MICs, then feel the relief of not having to care about collisions :) Nico -- From hartmans@mit.edu Thu May 27 17:27:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2673A69D8 for ; Thu, 27 May 2010 17:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys+4bj2TbS84 for ; Thu, 27 May 2010 17:26:58 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9A8BE3A699F for ; Thu, 27 May 2010 17:25:08 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3BEA320239; Thu, 27 May 2010 20:23:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B284A43EF; Thu, 27 May 2010 20:23:26 -0400 (EDT) From: Sam Hartman To: Sandra Murphy References: <20100520172310.GQ9605@oracle.com> Date: Thu, 27 May 2010 20:23:26 -0400 In-Reply-To: (Sandra Murphy's message of "Thu, 27 May 2010 14:56:26 -0400 (Eastern Daylight Time)") 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: manav.bhatia@alcatel-lucent.com, vishwas@ipinfusion.com, secdir@ietf.org, shares@nexthop.com, jjaeggli@checkpoint.com, Sam Hartman Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 00:27:16 -0000 >>>>> "Sandra" == Sandra Murphy writes: Sandra> I was discussing this just this morning with a colleague. Sandra> The discussion of pre-image and collision points out that Sandra> using collisions as an attack on a routing protocol is not Sandra> that easy since routing protocols have format requirements - Sandra> the attacker would have to find a collision that is also a Sandra> validly formatted protocol packet. I actually find this argument uncompelling. Certificates have format requirements, but we've generally found that extensible data structures typically have space somewhere for the bits that you need to make an attack possible. What's more interesting to me is the affect of the key on the ability to prepare for such an attack. From hartmans@mit.edu Thu May 27 17:33:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EA23A6916 for ; Thu, 27 May 2010 17:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.58 X-Spam-Level: X-Spam-Status: No, score=-0.58 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PAoHWcYOPDi for ; Thu, 27 May 2010 17:33:40 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BB3C43A68DE for ; Thu, 27 May 2010 17:33:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3C0A620239; Thu, 27 May 2010 20:33:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ACA2E43EF; Thu, 27 May 2010 20:33:00 -0400 (EDT) From: Sam Hartman To: "Bhatia\, Manav \(Manav\)" References: <20100520172310.GQ9605@oracle.com> <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 27 May 2010 20:33:00 -0400 In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com> (Manav Bhatia's message of "Fri, 28 May 2010 04:31:55 +0530") 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: "vishwas@ipinfusion.com" , "secdir@ietf.org" , "shares@nexthop.com" , "jjaeggli@checkpoint.com" , Sam Hartman Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 00:33:41 -0000 >>>>> "Bhatia," == Bhatia, Manav (Manav) writes: Bhatia,> this - "Attacks on many applications of MD5 are practical Bhatia,> on modern computers. For this reason the general use of Bhatia,> these algorithms should to be discouraged.[ Right. I think this text is misleading to the point of being false. There are attacks against md5 as a hash. However we have not yet found a mechanism to turn attacks on md5 as a hash into attacks on hmac-md5 as a MAC. It's not a question of the computer power--it's that thes attacks haven't managed to give an advantage for attacking HMAC. For other keyed md5 varients more analysis is required, but I would not at all be surprised if the conclusion were the same: the class of md5 attacks we know about do not apply to md5 in these MAC constructions. I think the best we can say for discouraging the use of md5 is something like "There have been attacks against the use of md5 as a hash; while these attacks do not directly apply to the use of MD5 in routing protocols, it is prudent to have other options available." The current text implies that the format of the routing packets, rather than the format of the MAC construction is what provides protection. Based on what we've learned about attacking certificates and based on the fact that all our routing protocols have some extension mechanisms, I'd find a defense based on the structure of the packets incredibly weak. From weiler@watson.org Thu May 27 23:52:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171E63A67AD for ; Thu, 27 May 2010 23:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoHBDCMDRAjC for ; Thu, 27 May 2010 23:52:55 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id D9F5C3A6817 for ; Thu, 27 May 2010 23:52:54 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o4S6qi2O088491 for ; Fri, 28 May 2010 02:52:44 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o4S6qiJK088488 for ; Fri, 28 May 2010 02:52:44 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 28 May 2010 02:52:44 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 28 May 2010 02:52:44 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 28 May 2010 06:52:56 -0000 It's been a quiet week in the world of IETF last calls: there are no new assignments at all. Charlie Kaufman is still next in the rotation. -- Sam For telechat 2010-06-03 Paul Hoffman T 2010-06-01 draft-ietf-avt-rapid-rtp-sync-10 Jeffrey Hutzelman T 2010-06-01 draft-ietf-nsis-ntlp-sctp-12 Tom Yu TR2010-06-01 draft-krishnan-v6ops-teredo-update-07 Larry Zhu T 2010-06-01 draft-santoni-media-type-tsd-00 For telechat 2010-06-17 Stephen Farrell T 2010-06-15 draft-kucherawy-authres-header-b-01 Last calls and special requests: Rob Austein 2010-05-14 draft-ietf-bmwg-protection-term-08 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-05 Alan DeKok 2010-05-12 draft-ietf-netconf-monitoring-13 Shawn Emery 2010-05-17 draft-ietf-mboned-ipv4-uni-based-mcast-06 Tobias Gondrom 2010-05-11 draft-ietf-tsvwg-dtls-for-sctp-05 Sam Hartman 2010-05-27 draft-ietf-avt-srtp-not-mandatory-05 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Love Hornquist-Astrand 2010-05-31 draft-ietf-ipsecme-eap-mutual-02 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows 2010-05-04 draft-ietf-tsvwg-dtls-for-sctp-05 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Sam Weiler 2010-05-19 draft-hoffman-tls-additional-random-ext-01 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 From hartmans@mit.edu Fri May 28 06:33:24 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569273A68A3 for ; Fri, 28 May 2010 06:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXydxa97SWqJ for ; Fri, 28 May 2010 06:33:23 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 8FF693A681B for ; Fri, 28 May 2010 06:33:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A6981202FB; Fri, 28 May 2010 09:33:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EE10A43EF; Fri, 28 May 2010 09:32:37 -0400 (EDT) From: Sam Hartman To: Sam Hartman References: <20100520172310.GQ9605@oracle.com> <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Fri, 28 May 2010 09:32:37 -0400 In-Reply-To: (Sam Hartman's message of "Thu, 27 May 2010 20:33:00 -0400") 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: "jjaeggli@checkpoint.com" , "shares@nexthop.com" , "Bhatia, Manav \(Manav\)" , "vishwas@ipinfusion.com" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 13:33:24 -0000 Hi. I was attempting to reconcile this draft against draft-ietf-rpsec-ospf-vuln, an old draft on OSPF vulnerabilities. Section 4.2.2.4 of the rpsec draft disagrees with the last paragraph of section 2 of the opsec draft. That paragraph talks about the attack in which the IP address of a hello packet is replayed in order to cause a node to think that a connection is not bidirectional. The rpsec draft argues that attack doesn't work because the router ID, not the source address is used. The rpsec draft also kind of implies this may depend on implementations. I'm not sure which draft is right. However, since there has been argument about whether this attack is possible,the opsec draft needs to either acknowledge or resolve this issue. (Obviously, I'd prefer that you resolve the issue: it makes our lives easier in karp, but if you don't have time, I understand just describing it.) In particular, I believe the opsec draft should cite as an informative reference section 4.2.4 of draft-ietf-rpsec-ospf-vuln 9 aand do one of the following: * Agree with the conclusions * State it is an implementation matter whether a particular implementation is vulnerable * Explain why the rpsec draft is wrong * Note that the issue is open Thanks, --Sam From Sandra.Murphy@cobham.com Fri May 28 09:14:05 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3763A6A3E for ; Fri, 28 May 2010 09:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+h6yaz5Tw51 for ; Fri, 28 May 2010 09:14:03 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 1441C3A6960 for ; Fri, 28 May 2010 09:14:02 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o4SFMWrN018099; Fri, 28 May 2010 10:22:32 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o4SFMUhw018807; Fri, 28 May 2010 10:22:31 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.107]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 May 2010 11:22:30 -0400 Date: Fri, 28 May 2010 11:22:30 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Vishwas Manral In-Reply-To: Message-ID: References: <20100520172310.GQ9605@oracle.com> <7539F1875DE542E7803619C575355E02@vishwasd520> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 May 2010 15:22:30.0735 (UTC) FILETIME=[96C325F0:01CAFE79] Cc: manav.bhatia@alcatel-lucent.com, secdir@ietf.org, shares@nexthop.com, jjaeggli@checkpoint.com, 'Sam Hartman' Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 16:14:05 -0000 On Thu, 27 May 2010, Vishwas Manral wrote: > Hi Sandra, > >> I really did mean what I said - if you can think of cases where >> routing protocols could be damaged by a collision attack, speak up. > I am sorry if you anywhere felt that I did not feel you really meant what > you said. Here I was, trying to be reassuring that there really was no sly subtext to what I said, and you seem to have taken it as a complaint, so I further confused things. Sorry. > > What you seem to be saying is pretty well known. I have given you an example > where if we can get a changed valid packet with a different topology, we can > cause blackholes, loops and redirection. > > Are you trying to figure out how a wrong topology description packet can > cause problems? Certainly wrong topology descriptions are a bad thing. I'm trying to distinguish damage that can be caused by collision attacks only. To be a collision attack, the attacker must be able to produce two packets that have the same hash. Since the use here is a keyed crypto hash, the hash also has to be validatable by the recipient - or there's no problem. Since we are NOT discussing failures in keyed MD5 that would permit someone who did not know the key to produce a valid digest, it must be the case that the attacker is someone who knows the key - in other words a valid participant. So. What would a collision attack allow a valid participant to do that a valid participant could not already do? We know for sure that valid participants can transmit "wrong topology descriptions" without resorting to the trouble of finding a hash collision between packets. I'm not taking potshots. I'm genuinely interested in the answer. Do you see any new damage that could be done only with a collision attack? --Sandy > > Thanks, > Vishwas > > -----Original Message----- > From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] > Sent: Thursday, May 27, 2010 12:30 PM > To: Vishwas Manral > Cc: 'Sam Hartman'; 'Nicolas Williams'; shares@nexthop.com; > jjaeggli@checkpoint.com; manav.bhatia@alcatel-lucent.com; secdir@ietf.org > Subject: RE: [secdir] Review of > draft-ietf-opsec-routing-protocols-crypto-issues-04 > > > > On Thu, 27 May 2010, Vishwas Manral wrote: > >> Hi Sam/ Sandra, >> >> I agree with what you guys have said, we can work to refine the wording to >> make it clear that there are no known attacks. >> >> There may not be known attacks based on collision, but that does not >> preclude future issues that may result. One thing I can see is if we can >> change the topology field and still have the right/ same hash, it could > lead >> to basic issues like traffic redirection, black holes and routing loops. I >> agree the fact that the packet needs to be a valid format packet makes the >> attack considerably harder. > > I really did mean what I said - if you can think of cases where routing > protocols could be damaged by a collision attack, speak up. > > Most of the things I could think of were attacks that resulted from a > legitimate participant behaving badly, and we all know just how much > risk routing protocols face from legitimate participants behaving badly > anyway - collisions would be no more risk. > > --Sandy > > >> >> Thanks, >> Vishwas >> >> -----Original Message----- >> From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] >> Sent: Thursday, May 27, 2010 11:56 AM >> To: Sam Hartman >> Cc: Nicolas Williams; shares@nexthop.com; jjaeggli@checkpoint.com; >> manav.bhatia@alcatel-lucent.com; vishwas@ipinfusion.com; secdir@ietf.org >> Subject: Re: [secdir] Review of >> draft-ietf-opsec-routing-protocols-crypto-issues-04 >> >> I was discussing this just this morning with a colleague. >> >> The discussion of pre-image and collision points out that using collisions >> as an attack on a routing protocol is not that easy since routing >> protocols have format requirements - the attacker would have to find a >> collision that is also a validly formatted protocol packet. >> >> Even beyond that, if the authors can point to some damage an attacker >> could do in a routing protocol using a collision, that would be very >> interesting. >> >> >> --Sandy >> >> On Thu, 27 May 2010, Sam Hartman wrote: >> >>>>>>>> "Nicolas" == Nicolas Williams writes: >>> >>> Nicolas> I have reviewed this document as part of the security >>> Nicolas> directorate's ongoing effort to review all IETF documents >>> Nicolas> being processed by the IESG. Document editors and WG chairs >>> Nicolas> should treat these comments just like any other last call >>> Nicolas> comments. >>> >>> Nicolas> This document aims to be an Informational RFC describing >>> Nicolas> security problems with various routing protocols. >>> >>> Nicolas> Aside from various spelling and other nits that the >>> Nicolas> RFC-Editor can easily handle, I have no issues with this >>> Nicolas> document and it is ready for publication. >>> >>> This document talks a lot about collision attacks against MD5 and then >>> draws the conclusion that MD5 should not be used as part of a MAC. I >>> agree that it is prudent to provide alternatives to MD5. However, I >>> think the current text implies that collision attacks against MD5 are >>> applicable to attacks against the use of MD5 in routing protocols. >>> >>> There is an introductory section that describes the difference between >>> pre image and collision attacks, but the rest of the document seems to >>> ignore the advice of that section. >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> >> >> > > From hartmans@mit.edu Fri May 28 09:53:54 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0DA23A696F for ; Fri, 28 May 2010 09:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0TK+5DX7qtr for ; Fri, 28 May 2010 09:53:54 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 228783A6955 for ; Fri, 28 May 2010 09:53:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E07C2203C0; Fri, 28 May 2010 12:53:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1257440CC; Fri, 28 May 2010 12:53:05 -0400 (EDT) From: Sam Hartman To: Sandra Murphy References: <20100520172310.GQ9605@oracle.com> <7539F1875DE542E7803619C575355E02@vishwasd520> Date: Fri, 28 May 2010 12:53:05 -0400 In-Reply-To: (Sandra Murphy's message of "Fri, 28 May 2010 11:22:30 -0400 (Eastern Daylight Time)") 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: manav.bhatia@alcatel-lucent.com, Vishwas Manral , secdir@ietf.org, shares@nexthop.com, jjaeggli@checkpoint.com, 'Sam Hartman' Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 16:53:55 -0000 Sandra> Since we are NOT discussing failures in keyed MD5 that would Sandra> permit someone who did not know the key to produce a valid Sandra> digest, it must be the case that the attacker is someone who Sandra> knows the key - in other words a valid participant. Sandra> So. What would a collision attack allow a valid participant Sandra> to do that a valid participant could not already do? We Sandra> know for sure that valid participants can transmit "wrong Sandra> topology descriptions" without resorting to the trouble of Sandra> finding a hash collision between packets. O! I finally understand your question. Intuitively the answer is that the attacker should not be able to do anything with a collision that they cannot already do by knowing the key, so I didn't even consider that you could be asking this question. Of course, with many intuitive things, when you actually question the intuition, it's not obvious why it's true. However I think I've come up with an argument. For a collision attack to be valuable to the person producing the hash, the hash needs to be consumed at multiple points in time. The attacker wins by having the hash consumed associated with m1 at one point and m2 at another point. For example, consider the attack where I sign m1 and then later claim to have signed m2. That attack is interesting because someone remembers the hash or at least depends on the hash and then later is asked to consider the second message with a given hash. >From this, I think that if the cryptographic hash is only used to verify a packet transmitted along-side the hash that a collision is not useful. The attacker could have simply sent another packet with a different hash. Here are some cases though which a protocol might engage in where this does not fit: 1) Participants use the hash to identify which packets they've seen in the past 2) Participants use hashes to see which packets other participants have already seen 3) Participants use hashes to identify the base of some delta to an object So any case where the lifetime of the hash is longer than just the MAC verification, I think there is at least the potential for a collision to be valuable. I believe at least for OSPF, the attacker gains nothing from collision attacks. IS-IS may be more complicated because I think there it's the content that is MACed not the packet. From suresh.krishnan@ericsson.com Sun May 30 22:37:45 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52E93A69C2; Sun, 30 May 2010 22:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4rZx4F27q7Z; Sun, 30 May 2010 22:37:44 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 1845C3A69C0; Sun, 30 May 2010 22:37:43 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o4V5bRSm000699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 May 2010 00:37:27 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.2.234.1; Mon, 31 May 2010 01:37:26 -0400 Message-ID: <4C034A8C.9020205@ericsson.com> Date: Mon, 31 May 2010 01:35:08 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Richard Barnes References: <00CEF527-9674-47CF-BC3E-66A9FC7289F7@bbn.com> In-Reply-To: <00CEF527-9674-47CF-BC3E-66A9FC7289F7@bbn.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: The IETF , "iesg@ietf.org" , "draft-ietf-csi-send-cert@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-csi-send-cert-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 05:37:46 -0000 Hi Richard, Thanks a lot for your extensive review. Please find responses inline. Richard Barnes 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. > > This document defines a certificate profile for use in the Secure > Neighbor Discovery protocol for IPv6. Starting from the RPKI cert > profile, it adds some refinements for SEND, e.g., EKUs that authorize > the subject to act in certain roles within SEND (router, proxy, host). > > Overall, the document is reasonably well-written, but could benefit > from more precision in its use of terminology. There are a few points > (noted below) where certificate processing rules are unclear. With > regard to the security considerations in particular, I would prefer if > they stated the risks slightly more directly (text is suggested > below), but in general, the authors address the major security concerns. > > Detailed comments follow. > > --Richard > > > Sec 2 Para 1 > Suggest changing "authority over an" to "authorization to advertise an". OK. > > Sec 2 Para 2 > Suggest rewording to avoid referring to SIDR WG (which is temporary). > Suggested text: "The Resource Public Key Infrastructure (RPKI) is the > global PKI that attests to allocation of IP address space." Also, > instead of "SIDR certificate profile", use "RPKI certificate profile". Sounds good. > > Sec 2 Para 3, General > I'm confused by the several instances of the phrase "address owner" in > the document (the phrase is not used in RFC 3971). Do you mean "host"? Since RFC3971 did not expect hosts to use certificates to defend their addresses (hosts traditionally use CGAs), this role was not defined. I proposed the following text to explain what the address owner role means The inclusion of the owner authorization value indicates that the certificate has been issued for allowing the node to use the address(es) or prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779]. For an address in such certificate the host can assign the address, send/receive traffic from this address, and can respond to NSes about that address. For a prefix in such certificate the node can perform all the above mentioned operations for any address in that prefix. Also, when a prefix is present in the certificate with the owner authorization value, the node cannot advertise the prefix in an RA. This will replace paragraph 6 of section 7. Does this work? > > Sec 3 Para "End Entity" > This definition is incorrect. Refer to RFC 4949. Can we use "End Entity - an entity that is not a CA" > > Sec 4 Para 1 > The RPKI profile should be applied in *addition* to the RFC 3971 > profile, right? Please clarify. Not really. The csi wg decided to base the new SEND certificate profile solely on the RPKI profile. > > Sec 4 Para 2 > Why can there only be one RFC 3779 extensions? It doesn't seem like > there's a risk in including IPv4 space (e.g., for a dual-stack router > that was vouching for IPv4 space in some other application?), or > multiple extensions for IPv6 space. I am not sure where this restriction is specified. Can you clarify? > > Sec 5 > This section should note that another deployment model (arguably the > most likely) is a combination of these two, in which most resources > are certified under the global RPKI, while some (e.g., ULAs) are > certified under local TAs. Sounds good. Will add the following text about a hybrid deployment model at the end of section 5. " These two models are not mutually exclusive. It is entirely possible to have a hybrid model that incorporates features from both these models. In one such hybrid deployment model most IP address resources (e.g. global unicast addresses) would be certified under the global RPKI, while some others (e.g., ULAs) are certified under local TAs." > > Sec 6 Para 4 > The requirement for RFC 3779 extension seems to contradict the use of > ETAs as Trust Anchor Material, i.e., the last sentence of the first > paragraph in this section. Good catch. I am not sure how to resolve this. One way would be to specify that the ETA EE certificates are exempt from requiring the RFC3779 extensions. Do you have any suggestions? > > Sec 7 Para "The inclusion of ..." et seq. > It would be helpful for the document to specify how prefix matching > should be done when validating these extensions. Which of the > following should the RP use? > -- Exact matching > -- Subset matching (RA within cert) > -- The weird subset/intersection algorithm that RFC 3971 defines > What prefix should the RP be matching against from SEND, per EKU? > E.g., for id-kp-sendRouter, the RFC 3779 extension in the cert should > match against any RAs the router emits. It may be useful to refer to > the ROA validation document [draft-ietf-sidr-roa-validation]. My gut feel is subset matching, but we need to make sure this will work with all scenarios. We will come back with text proposals for this. > > Sec 7 Para "Certificate-using applications..." > Suggest changing "Certificate-using applications" to "Relying Parties". OK. > > Sec 8 > This section correctly identifies the main risk with these extensions > (namely, issuance of certs with incorrect roles assigned), but it > would be helpful to clarify the application-level impact of these bad > issuances. Suggested text: > " > " I will include this text in the security considerations section. Thanks Suresh From hartmans@mit.edu Mon May 31 05:08:28 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9740A3A68BE for ; Mon, 31 May 2010 05:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.379 X-Spam-Level: X-Spam-Status: No, score=0.379 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHHkoAvHfrBs for ; Mon, 31 May 2010 05:08:27 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B17BE3A6826 for ; Mon, 31 May 2010 05:08:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [213.197.167.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 53C4320394; Mon, 31 May 2010 08:08:11 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E42C540AB; Mon, 31 May 2010 08:08:05 -0400 (EDT) From: Sam Hartman To: "Bhatia\, Manav \(Manav\)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCEB21B3E@INBANSXCHMBSA1.in.alcatel-lucent.com> (Manav Bhatia's message of "Sat, 29 May 2010 05:07:56 +0530") Date: Mon, 31 May 2010 03:36:10 -0400 Message-ID: References: <20100520172310.GQ9605@oracle.com> <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CCEB21B3E@INBANSXCHMBSA1.in.alcatel-lucent.com> 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: "jjaeggli@checkpoint.com" , "shares@nexthop.com" , Sam Hartman , "vishwas@ipinfusion.com" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 12:08:28 -0000 >>>>> "Bhatia," == Bhatia, Manav (Manav) writes: Bhatia,> I am aware of some implementations that look at the IP Bhatia,> header to determine the source. I think it's a very good Bhatia,> catch and we could append the following before the original Bhatia,> text: "In some OSPF implementations neighbors on broadcast Bhatia,> .. " Bhatia,> Does this sound acceptable? Yes. I'd still add a citation to the old draft, but I think that your text change brings things nicely into alignment. Then, in KARP, we can figure out what we recommend about this. From manav.bhatia@alcatel-lucent.com Thu May 27 16:02:20 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134143A69EB for ; Thu, 27 May 2010 16:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syV-iZR-g+XB for ; Thu, 27 May 2010 16:02:19 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 0022E3A69DE for ; Thu, 27 May 2010 16:02:16 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o4RN1xb2010781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 May 2010 18:02:02 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o4RN1vJA000556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 May 2010 04:31:57 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 28 May 2010 04:31:57 +0530 From: "Bhatia, Manav (Manav)" To: Sam Hartman , Nicolas Williams Date: Fri, 28 May 2010 04:31:55 +0530 Thread-Topic: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 Thread-Index: Acr9zStFnVtOJ7J9Shy7FXBVK4VIRwAImYKg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20100520172310.GQ9605@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 X-Mailman-Approved-At: Mon, 31 May 2010 08:13:49 -0700 Cc: "shares@nexthop.com" , "jjaeggli@checkpoint.com" , "vishwas@ipinfusion.com" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 23:02:20 -0000 Hi Sam, >=20 > This document talks a lot about collision attacks against MD5 and then > draws the conclusion that MD5 should not be used as part of a MAC. I > agree that it is prudent to provide alternatives to MD5. However, I > think the current text implies that collision attacks against MD5 are > applicable to attacks against the use of MD5 in routing protocols. Not really. We do mention this at the beginning: " The ability to produce a collision does not currently introduce any obvious or known attacks on routing protocols. Pre-image attacks have the potential to cause problems in the future albeit due to the message length there are serious limitations to the feasibility of mounting such an attack. Protocols themselves have some built-in protection against collision attacks. This is because a lot of values for fields in a protocol packet are invalid or will produce an unusable packet. For example, in OSPF the LSA type can be from 1 to 11. Any other value in the field will result in the packet being discarded. Assume two packets M and M' are generated which have the same hash. The above condition will further reduce the ability to produce a message which is also a correct message from the protocol perspective, as a lot of potential values are themselves not valid." >=20 > There is an introductory section that describes the difference between > pre image and collision attacks, but the rest of the document seems to > ignore the advice of that section. I think what we're trying to say is the following: Routing Protocols currently use MD5. There are attacks against MD5, but the= y may not lead to routing vulnerabilities (Sec 1.1). However, we discourage= the use of such algorithms. The exact text that we used for OSPF is this -= "Attacks on many applications of MD5 are practical on modern computers. Fo= r this reason the general use of these algorithms should to be discouraged.= [RFC5709] adds support for using HMAC-SHA with OSPF." We have currently not found direct vulnerabilities when using MD5 with Rout= ing protocols, but going forward one could actually construct a packet that= could adversely affect routing protocol functioning. Manav > = From new-work-bounces@ietf.org Fri May 28 05:10:42 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044593A68A2; Fri, 28 May 2010 05:10:28 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD533A6A15 for ; Fri, 28 May 2010 05:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.751 X-Spam-Level: * X-Spam-Status: No, score=1.751 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_99=3.5, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH0XK3m1zHnb for ; Fri, 28 May 2010 05:10:18 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 015003A659B for ; Fri, 28 May 2010 05:10:18 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lkfu8-1NhXdh1UbU-00ayr3; Fri, 28 May 2010 08:10:06 -0400 Message-ID: From: "Spencer Dawkins" To: Date: Fri, 28 May 2010 07:09:55 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Provags-ID: V01U2FsdGVkX1+c6BGKepWRzE06+0iF/aFkT1AWYrO/zDfN5x/ Nyx6SJT35T/OTQDxC7ViZ5Evwd+USR42D7t9Wn9/brOU0K2iKx 2U4l2D7VaSryTe/ji9PhjPhyGxKDxQUqQWKB+P+89w= X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 31 May 2010 08:13:49 -0700 Subject: [secdir] [New-work] Verifying SDO participation in New-Work 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, 28 May 2010 12:10:42 -0000 The IAB is reviewing the use of the "New-Work" mailing list (new-work@ietf.org) (background information at http://www.tla-group.com/~loa/new-work-01.htm), as part of the IAB's oversight role for external liaisons under RFC 2850 ("Charter of the Internet Architecture Board"). This mailing list was established to facilitate exchange of information regarding new work considered and/or started in any organizations that develop technical specifications or standards related to the Internet. The areas of interest often overlap between two or more organizations. As part of our review, we would like to understand which SDOs are currently participating in the mailing list. The most recent SDO membership roster we have for this list is: ECMA International ETSI IEEE 802.1 IETF ITU-T JTC1 MFA (we know MFA has been merged into BBF) OASIS OMA OMG SNIA TIA TM Forum The Open Group W3C Could you reply to this e-mail (to spencer@wonderhamster.org) and - confirm that you're still participating in "new-work" - confirm what SDOs you are partcipating on behalf of It would be very helpful if you could respond by 11 June 2010, although responses after that are still appreciated. Thanks, Spencer Dawkins, for the Internet Architecture Board _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From manav.bhatia@alcatel-lucent.com Fri May 28 16:38:20 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3663A6A60 for ; Fri, 28 May 2010 16:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_40=-0.185, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyu55V2wJYr7 for ; Fri, 28 May 2010 16:38:19 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id A32C23A6961 for ; Fri, 28 May 2010 16:38:19 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o4SNc2Bn020031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 May 2010 18:38:04 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o4SNbwAG029963 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 29 May 2010 05:07:59 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sat, 29 May 2010 05:07:58 +0530 From: "Bhatia, Manav (Manav)" To: Sam Hartman Date: Sat, 29 May 2010 05:07:56 +0530 Thread-Topic: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 Thread-Index: Acr+alerd9AWMW+EScaXLmAYdfvDsQAVAt6Q Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCEB21B3E@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20100520172310.GQ9605@oracle.com> <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 X-Mailman-Approved-At: Mon, 31 May 2010 08:13:49 -0700 Cc: "jjaeggli@checkpoint.com" , "shares@nexthop.com" , "vishwas@ipinfusion.com" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 23:38:20 -0000 I am aware of some implementations that look at the IP header to determine = the source. I think it's a very good catch and we could append the followin= g before the original text: "In some OSPF implementations neighbors on broadcast .. "=20 Does this sound acceptable? Cheers, Manav > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Friday, May 28, 2010 7.03 PM > To: Sam Hartman > Cc: Bhatia, Manav (Manav); vishwas@ipinfusion.com;=20 > secdir@ietf.org; shares@nexthop.com; jjaeggli@checkpoint.com > Subject: Re: [secdir] Review of=20 > draft-ietf-opsec-routing-protocols-crypto-issues-04 >=20 > Hi. I was attempting to reconcile this draft against > draft-ietf-rpsec-ospf-vuln, an old draft on OSPF vulnerabilities. > Section 4.2.2.4 of the rpsec draft disagrees with the last=20 > paragraph of > section 2 of the opsec draft. That paragraph talks about the=20 > attack in > which the IP address of a hello packet is replayed in order to cause a > node to think that a connection is not bidirectional. The rpsec draft > argues that attack doesn't work because the router ID, not the source > address is used. The rpsec draft also kind of implies this may depend > on implementations. >=20 > I'm not sure which draft is right. However, since there has been > argument about whether this attack is possible,the opsec=20 > draft needs to > either acknowledge or resolve this issue. (Obviously, I'd prefer that > you resolve the issue: it makes our lives easier in karp, but if you > don't have time, I understand just describing it.) >=20 > In particular, I believe the opsec draft should cite as an informative > reference section 4.2.4 of draft-ietf-rpsec-ospf-vuln =20 > 9 > aand do one of the following: >=20 > * Agree with the conclusions >=20 > * State it is an implementation matter whether a particular > implementation is vulnerable >=20 > * Explain why the rpsec draft is wrong >=20 > * Note that the issue is open >=20 > Thanks, >=20 > --Sam > = From manav.bhatia@alcatel-lucent.com Fri May 28 17:00:17 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5FE3A6924 for ; Fri, 28 May 2010 17:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.104 X-Spam-Level: X-Spam-Status: No, score=0.104 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPWb1sFY2OdZ for ; Fri, 28 May 2010 17:00:16 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 5CE5B3A6897 for ; Fri, 28 May 2010 17:00:16 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o4SNxw1P022936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 May 2010 19:00:00 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o4SNxueA018377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 29 May 2010 05:29:57 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sat, 29 May 2010 05:29:56 +0530 From: "Bhatia, Manav (Manav)" To: Sam Hartman Date: Sat, 29 May 2010 05:29:55 +0530 Thread-Topic: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 Thread-Index: Acr9/Wk3BXNW2r8oTPSV2Q8txowtrAAwslHg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCEB21B40@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20100520172310.GQ9605@oracle.com> <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 X-Mailman-Approved-At: Mon, 31 May 2010 08:13:49 -0700 Cc: "secdir@ietf.org" , "vishwas@ipinfusion.com" , "jjaeggli@checkpoint.com" Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 00:00:17 -0000 =20 >=20 > For other keyed md5 varients more analysis is required, but I=20 > would not > at all be surprised if the conclusion were the same: the class of md5 > attacks we know about do not apply to md5 in these MAC constructions. >=20 > I think the best we can say for discouraging the use of md5=20 > is something > like "There have been attacks against the use of md5 as a hash; while > these attacks do not directly apply to the use of MD5 in routing > protocols, it is prudent to have other options available." >=20 > The current text implies that the format of the routing=20 > packets, rather > than the format of the MAC construction is what provides protection. > Based on what we've learned about attacking certificates and based on > the fact that all our routing protocols have some extension=20 > mechanisms, > I'd find a defense based on the structure of the packets incredibly > weak. Though I agree that the current attacks on MD5 do not currently apply to MD= 5 as used in routing protocols, I still think very strongly about our point= that for an attack to happen we would need a completely acceptable packet = format which may not happen and thereby reducing the probability of an atta= ck. In cryptography one can never be sure of what all has already been brok= en (It was several years till it became common public knowledge about "enig= ma" cipher being broken) and its precisely the routing protocol packet form= at that provides an additional level of security. Assume a 64 byte OSPF HEL= LO packet using keyed MD5 as described in 2328. Assume that we have been ab= le to find collisions with MD5 as used by OSPF. Even if we are able to find= collisions, the probability of an attacker doing something meaningful is i= n the order of 1/2^64 for a given source and a dest IP. Thus this really is the clincher in my opinion. Thanks, Manav= From rbarnes@bbn.com Mon May 31 17:23:15 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDF63A6891; Mon, 31 May 2010 17:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cVSjrq5m4+i; Mon, 31 May 2010 17:23:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 08F5E3A687C; Mon, 31 May 2010 17:23:13 -0700 (PDT) Received: from [128.89.255.218] (port=60533 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJFG0-000Dnk-Ck; Mon, 31 May 2010 20:23:01 -0400 Message-Id: From: "Richard L. Barnes" To: Suresh Krishnan In-Reply-To: <4C034A8C.9020205@ericsson.com> Content-Type: multipart/alternative; boundary=Apple-Mail-3-691834140 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 31 May 2010 20:22:57 -0400 References: <00CEF527-9674-47CF-BC3E-66A9FC7289F7@bbn.com> <4C034A8C.9020205@ericsson.com> X-Mailer: Apple Mail (2.936) Cc: The IETF , "iesg@ietf.org" , "draft-ietf-csi-send-cert@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-csi-send-cert-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 00:23:15 -0000 --Apple-Mail-3-691834140 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hey Suresh, Most of these comments look OK to me. Couple of responses inline. --Richard > The inclusion of the owner authorization value indicates that the > certificate has been issued for allowing the node to use the > address(es) or prefix(es) that are mentioned using the X.509 > extensions for IP addresses and AS identifiers [RFC3779]. For an > address > in such certificate the host can assign the address, send/receive > traffic from this address, and can respond to NSes about that address. > For a prefix in such certificate the node can perform all the above > mentioned operations for any address in that prefix. Also, when a > prefix > is present in the certificate with the owner authorization value, the > node cannot advertise the prefix in an RA. > > This will replace paragraph 6 of section 7. Does this work? Ok, I understand the difficulty more now, and that text looks fine. >> Sec 3 Para "End Entity" >> This definition is incorrect. Refer to RFC 4949. > > Can we use > > "End Entity - an entity that is not a CA" Might want to note that the entity in question is the subject of a certificate in the PKI rather than, say, my cat (which, AFAIK, does not hold any certificates). Suggested text: "End Entity - An entity in the PKI that is not a CA" >> Sec 4 Para 1 >> The RPKI profile should be applied in *addition* to the RFC 3971 >> profile, right? Please clarify. > > Not really. The csi wg decided to base the new SEND certificate > profile solely on the RPKI profile. Ok, that should be clearer in the document. Suggest adding this after the first sentence of Section 4: "This certificate profile supercedes the profile for router certificates specified in RFC 3971. That is, certificates used in SEND (by routers, proxies, or address owners) MUST conform to this certificate profile and MAY conform to the original profile in RFC 3971." >> Sec 4 Para 2 >> Why can there only be one RFC 3779 extensions? It doesn't seem >> like there's a risk in including IPv4 space (e.g., for a dual- >> stack router that was vouching for IPv4 space in some other >> application?), or multiple extensions for IPv6 space. > > I am not sure where this restriction is specified. Can you clarify? The text I was referring to is the following: " SEND certificates MUST include the IP Resources extension for IPv6 Address Family (AFI=0002) described in section 3.9.10 of [I-D.ietf- sidr-res-certs] and MUST be the only resource extension present. " I had read this to mean that the only resources that could be in the certificate could be a single IPv6 address block. Suggest replacing with the following clarification: " SEND certificates MUST include the IP Resources extension [RFC3779]. This extension MUST include at least one address block for the IPv6 Address Family (AFI=0002), as described in Section 3.9.10 of [I-D.ietf- sidr-res-certs]. SEND certificates MUST NOT have more than one IP Resources extension. " >> Sec 5 >> This section should note that another deployment model (arguably >> the most likely) is a combination of these two, in which most >> resources are certified under the global RPKI, while some (e.g., >> ULAs) are certified under local TAs. > > Sounds good. Will add the following text about a hybrid deployment > model at the end of section 5. > > " These two models are not mutually exclusive. It is entirely > possible > to have a hybrid model that incorporates features from both these > models. In one such hybrid deployment model most IP address > resources (e.g. global unicast addresses) would be certified under > the global RPKI, while some others (e.g., ULAs) are certified under > local TAs." That text looks good, thanks. >> Sec 6 Para 4 >> The requirement for RFC 3779 extension seems to contradict the use >> of ETAs as Trust Anchor Material, i.e., the last sentence of the >> first paragraph in this section. > > Good catch. I am not sure how to resolve this. One way would be to > specify that the ETA EE certificates are exempt from requiring the > RFC3779 extensions. Do you have any suggestions? I think the rest of the section is clear enough -- the TA material either has to be a self-signed certificate or it has to be an ETA. So maybe you could just delete the phrase "and MUST always refer to a certificate that includes a RFC 3779 address extension"? As an aside, do you want to specify that in the first case (the non- ETA case), the self-signed TA cert MUST conform to the RPKI profile? --Apple-Mail-3-691834140 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hey = Suresh,

Most of these comments look OK to me. =  Couple of responses = inline.

--Richard

<= br>
The inclusion of the owner = authorization value indicates that the
certificate has been issued = for allowing the node to use the
address(es) or prefix(es) that are = mentioned using the X.509
extensions for IP addresses and AS = identifiers [RFC3779]. For an address
in such certificate the host = can assign the address, send/receive
traffic from this address, and = can respond to NSes about that address.
For a prefix in such = certificate the node can perform all the above
mentioned operations = for any address in that prefix. Also, when a prefix
is present in the = certificate with the owner authorization value, the
node cannot = advertise the prefix in an RA.

This will replace paragraph 6 of = section 7. Does this work?

Ok, = I understand the difficulty more now, and that text looks = fine.


Sec 3 Para "End Entity"
This definition is incorrect.  Refer to RFC = 4949.

Can we use

"End Entity - an entity that = is not a CA"

Might want to = note that the entity in question is the subject of a certificate in the = PKI rather than, say, my cat (which, AFAIK, does not hold any = certificates).  Suggested text:
"End Entity - An entity = in the PKI that is not a CA"


Sec 4 Para = 1
The RPKI profile should be = applied in *addition* to the RFC 3971  profile, right?  Please = clarify.

Not really. The csi wg decided to base the = new SEND certificate profile solely on the RPKI = profile.

Ok, that should be = clearer in the document.  Suggest adding this after the first = sentence of Section 4:
"This certificate profile supercedes = the profile for router certificates specified in RFC 3971.  That = is, certificates used in SEND (by routers, proxies, or address owners) = MUST conform to this certificate profile and MAY conform to the original = profile in RFC 3971."


Sec 4 Para = 2
Why can there only be one = RFC 3779 extensions?  It doesn't seem like  there's a risk in = including IPv4 space (e.g., for a dual-stack router  that was = vouching for IPv4 space in some other application?), or  multiple = extensions for IPv6 space.

I am not sure where this = restriction is specified. Can you = clarify?

The text I was referring = to is the following:
"
SEND certificates MUST = include the IP Resources extension for IPv6 Address Family (AFI=3D0002) described in section 3.9.10 of [I-D.ietf-sidr-res-certs] and MUST be the only resource extension present.
"
I had read this to mean = that the only resources that could be in the certificate could be a = single IPv6 address block.  Suggest replacing with the following = clarification:
"
SEND certificates MUST include the = IP Resources extension [RFC3779].  This extension MUST include at = least one address block for the IPv6 Address Family (AFI=3D0002), as = described in Section 3.9.10 of [I-D.ietf-sidr-res-certs]. =  SEND certificates MUST NOT have more than one IP Resources = extension.
"



Sec = 5
This section should note = that another deployment model (arguably the  most likely) is a = combination of these two, in which most resources  are certified = under the global RPKI, while some (e.g., ULAs) are  certified under = local TAs.

Sounds good. Will add the following text = about a hybrid deployment model at the end of section 5.

" =  These two models are not mutually exclusive.  It is entirely = possible
  to have a hybrid model that incorporates = features from both these
  models.  In one such = hybrid deployment model most IP address
  resources (e.g. = global unicast addresses) would be certified under
  the = global RPKI, while some others (e.g., ULAs) are certified under
=   local TAs."

That= text looks good, thanks.


Sec 6 Para = 4
The requirement for RFC 3779 = extension seems to contradict the use of  ETAs as Trust Anchor = Material, i.e., the last sentence of the first  paragraph in this = section.

Good catch. I am not sure how to resolve = this. One way would be to specify that the ETA EE certificates are = exempt from requiring the RFC3779 extensions. Do you have any = suggestions?

I think the rest of = the section is clear enough -- the TA material either has to be a = self-signed certificate or it has to be an ETA.  So maybe you could = just delete the phrase "and MUST always refer to a certificate that = includes a RFC 3779 address = extension"?

As an aside, do you want to = specify that in the first case (the non-ETA case), the self-signed TA = cert MUST conform to the RPKI = profile?


= --Apple-Mail-3-691834140-- From paul.hoffman@vpnc.org Mon May 31 17:51:00 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026893A6819 for ; Mon, 31 May 2010 17:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zXADwqNjUPg for ; Mon, 31 May 2010 17:50:59 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id F16123A6817 for ; Mon, 31 May 2010 17:50:58 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o510oM4c090487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 May 2010 17:50:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 31 May 2010 17:50:21 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ts@thomas-schierl.de, csp@csperkins.org Subject: [secdir] SecDir review of draft-ietf-avt-rapid-rtp-sync-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 00:51:00 -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 comments. The extensions described in this document probably do not cause any security problems for the Internet. As the security considerations section says, the security of these extensions inherit most of the security considerations of RTP. >From my admittedly naive reading, it seems that an attacker could use one or more of these extensions to amplify a denial-of-service attack by causing nodes to try to synch when they can't; if so, that might be added to the security considerations section. However, this is a trivial point even if true, and the document is fine as-is. --Paul Hoffman, Director --VPN Consortium From secdir-bounces@mit.edu Mon May 31 19:00:38 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519F13A6909 for ; Mon, 31 May 2010 19:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sob6qgyLMYDx for ; Mon, 31 May 2010 19:00:37 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 528863A67C1 for ; Mon, 31 May 2010 19:00:36 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5120OhJ025575 for ; Mon, 31 May 2010 22:00:24 -0400 Received: from mailhub-dmz-1.mit.edu (MAILHUB-DMZ-1.MIT.EDU [18.9.21.41]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5120MV3025567 for ; Mon, 31 May 2010 22:00:22 -0400 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id o5120Dx1025568 for ; Mon, 31 May 2010 22:00:22 -0400 X-AuditID: 1209190f-b7b20ae000003f85-9e-4c0469b66b2b Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id 7A.2F.16261.6B9640C4; Mon, 31 May 2010 22:00:22 -0400 (EDT) Received: from [192.168.1.106] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o51209LX008145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 May 2010 22:00:18 -0400 (EDT) Date: Mon, 31 May 2010 22:00:09 -0400 From: Jeffrey Hutzelman To: iesg@ietf.org, secdir@mit.edu, draft-ietf-nsis-ntlp-sctp.all@tools.ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 X-Brightmail-Tracker: AAAAAA== X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] secdir review of draft-ietf-nsis-ntlp-sctp-12.txt 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, 01 Jun 2010 02:00:38 -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. The General Internet Signaling Transport (GIST) protocol, as defined in draft-ietf-nsis-ntlp-20.txt, provides for flexibility in selection of transport and lower-layer security protocols, but initially specifies only TCP and TLS-over-TCP. The present document extends GIST by adding support for SCTP and DTLS-over-SCTP. The security considerations section is quite short, incorporating by reference the security considerations of GIST, SCTP, and DTLS. This seems entirely reasonable, with the exception of the specific points mentioned below, which I'd like to see addressed directly. It is noted in multiple places that replay protection is not available when using DTLS over SCTP, with no further explanation other than a reference to draft-ietf-tsvwg-dtls-for-sctp (which itself says that the feature MUST NOT be used, but gives no explanation). In particular, there is no discussion as to what implications this has for GIST or for higher-layer protocols in the NSIS stack. Section 8 says DTLS support MUST be implemented, presumably by anything complying with the present document and thus anything which supports GIST over SCTP. It then goes on to say that an implementation of GIST over SCTP without PR-SCTP (and thus, where there is no change that individual TLS records will be dropped from the middle of the stream due to differing timeouts) MAY use TLS instead of DTLS. That is, it permits GIST-over-TLS-over-SCTP instead of GIST-over-DTLS-over-SCTP when the latter is not available (provided PR-SCTP is not used). Why would this ever be necessary? If DTLS is mandatory-to-implement, in what scenario would TLS be available but not DTLS? _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir