From msec-admin@securemulticast.org Mon Apr 1 21:21:34 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21910 for ; Mon, 1 Apr 2002 21:21:33 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EC5A453B08; Mon, 1 Apr 2002 21:19:00 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 30FF853965 for ; Mon, 1 Apr 2002 21:17:39 -0500 (EST) Received: (qmail 77325 invoked by uid 3269); 2 Apr 2002 02:19:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 77319 invoked from network); 2 Apr 2002 02:19:42 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 2 Apr 2002 02:19:42 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g322J2K25595; Mon, 1 Apr 2002 18:19:02 -0800 (PST) Received: from mbaugher-w2k1.cisco.com ([10.34.251.92]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABI38664; Mon, 1 Apr 2002 18:17:07 -0800 (PST) Message-Id: <4.3.2.7.2.20020401082919.04d67bc0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: jari.arkko@ericsson.com, elisabetta.carrara@era.ericsson.se, fredrik.lindholm@era.ericsson.se, Mats =?iso-8859-1?Q?N=E4slund?= , karl.norrman@era.ericsson.se From: Mark Baugher Cc: msec@securemulticast.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] comments on draft-ietf-msec-mikey-01.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 01 Apr 2002 18:17:54 -0800 I read the draft and have a number of comments. This looks like a complete draft. Glad to see that. I'll try to give a complete review. S 1.2: Why use "pre-master key" when there is no master key or post-master key used in the draft? The problem is that you tend to slip into using "master" to refer to the PMK as in section 4.1. S 2.1: You give four definitions for four scenarios but then introduce other types in the commentary: You introduce "one-to-many (one-to-'a few')" in the commentary but define "simple one-to-many" in scenario d, and then introduce "small-size interactive groups." This leaves me wondering what properties of the one-to-many are you addressing or not addressing? Also, you don't state which of the many-to-many scenarios you support or don't support and why. P 8, last para: What is mean't by "external" group re-key protocol. Why does MIKEY need to use re-key at all? I think that there is a media-on-demand (RTSP) scenario where it might be useful: If the media are pre-encrypted to off-load crypto operations from a media server, then pushing the session key protected by a KEK without registration might make a lot of sense rather than always requiring an authenticated key establishment. This is not addressed in MIKEY. If it were, it might be better done within the RTSP message rather than by some "external" protocol. As it is, I don't see the need for re-key in this draft. S 2.5: You tend to repeat that MIKEY is for real-time data, but I don't think the properties of the data-security protocol motivate the need for MIKEY as much as low-latency (one or two message) key establishment. I think MIKEY's motivation is low-latency key establishment and not real-time or continuous time data. S 3.0, 2nd para: "signing" should be "authentication" S 3.0, last para: I had a problem with the fact that you left the header, parameters and policies out of the flows because I could not easily see where the various payloads were used. The table in Appendix B is hard to use in my opinion. S 3.1 after Figure 3.1: "Authentication of the peers..." should be "Authentication of the message..." Also, shouldn't the initiator have a means to request that the responder send a verification message? S 3.2, fig 3.2: It appears that IDa is always sent and is encrypted whereas I is set to IDa or cert_a; do you mean to encipher I and not IDa? S 3.3: You state why DH might not be used but not why someone might choose to use it: PFS. P.13, 4th para from bottom: The signature covers the Initiator's Id: This is the I value that is either the ID or the cert, right? S 4.1, second bullet: Fig 3.2 derives a KEK from Rand so I am confused about the use of the DH values for deriving the KEK - it seemed like a KEK is derived only when DH is used. S 4.1.3: I found use of "inkey" to be confusing. It's the same as "s" where you introduce the notation to be used in 4.1.2, isn't it? S 4.1.4: The first note does not make sense. The second note should be "or the one" rather than "and the once." Is the source of the decimal digits arbitrary? S 4.2: I did not find any guidance for how new transforms are added to MIKEY. Also, if you have mandatory transforms, I don't see what the interoperability problems are that you caution against in this paragraph. S 4.2.3, note: :-) S 4.2.4: I got confused about the fact that MIKEY provides a framework where the transforms are upgradeable and replaceable; perhaps a separate section that lists the mandatory and default algorithms; perhaps more generality in the rest of the draft would help. S 4.4: It is not clear what your model is wrt the data security protocol. Does the latter maintain the SAs? This is what I would expect. It seems that MIKEY maintains the SAs since you have a MIKEY SA database. What is not clear to me is MIKEY's SAs (that would include the cached keys used for MIKEY key download) and the data security protocol (e.g. SRTP) SAs, which I expect the data security protocol will maintain. These are two different things. The IKE model is that the security protocol SA gets handed over to the security protocol and that is the end of the matter. Why not adopt this model? Also, 4.4 is very specific to one security protocol, SRTP. It might not be bad to support just SRTP, but other parts of the draft indicate that you want to support other protocols. If so, you need to generalize the mechanisms beyond SSRCs. S 4.5: Again, need for re-key in the gkmarch sense is not clear to me. It also is not clear to me who initiates MCS updating and how one end can recognize what the other end has or has not cached. S 5.2, fig 5.1: "Figure 5.1: MIKEY payload example" - "payload" should be "message." In the last bullet, "master payload" is mentioned but I don't know what this is. S 5.3: I would like to see flows that list the mandatory and optional payloads for each message in some order that might be optimal or at least as good as any order. It seems that every payload besides the header "payload" can be put in an arbitrary order and it's not clear until the very last page what payloads go with what messages. I find this hard to understand and evaluate. Also, in the third to the last bullet, why say the message "SHOULD" be processed if authentication is successful; otherwise, why begin processing the message at all? I don't see why in the second to the last bullet that an authentication failure is a MUST report and a protocol failure is a SHOULD report. Finally, the last bullet starts with "if needed" but does not give the conditions when such a thing is needed. S 5.4: Replay handling is very confusing to me and this section did not shed much light on it for me. Since signatures are used, the costs of getting this wrong are quite high. What are the scenarios for protecting against DoS? Are they different for attacks against RTSP servers? SIP initiators? SIP responders? What is the needed clock synchronization (I seem to recall some text about 5 minutes (!?) but it's apparently not in this section). I think we need a model to describe the interaction of replay attacks with various degrees of clock synch? How does this change when the particular entity is under attack? Do we need to worry about proxies? S 5.5: "transporting protocol" is a bit confusing I think because SDP in SIP or RTSP is a transporting protocol. I think you mean "on an unreliable transport" as distinct from SIP or some other protocol that carry's the MIKEY and ensures reliability S 6.1: A complete example would be reassuring. In fact, is there to be a reference implementation available sometime soon? S 6.2, 3rd para from end: "MIKEY must signal to SIP" is a bit sloppy since SIP is a protocol specification. I think you mean the SIP implementation. It would be better I suspect if we linked the protocols by mapping MIKEY error codes and result codes to SIP error/result codes. In this way, we might ensure that MIKEY failure definitely maps into SIP failure without the need to specify implementation behavior, i.e. we handle the linkage at the protocol level. S 6.3, last para: Would it make sense to select ANNOUNCE or SET_PARAMETER as the operation that tunnels the MIKEY message and say that these are mandatory to implement when MIKEY is used? It's clear that some changes are needed to the SIP or RTSP implementations (preceding note). S 6.4, first bullet: One interface option is to use the SA DB and API where the security protocol (SRTP) signals MIKEY through an application interface that results in updates to an update to SRTPs crypto context (SADB) by MIKEY. S 6.4, second bullet: This interface might be the mapping between MIKEY result codes and SIP or RTSP codes so the desired behavior of the host protocol (SIP, RTSP) is unambiguously defined. S 6.4, last bullet: Is there any need or possibility for carrying a MIKEY "de-registration" or "tear-down" message? such a message could explicitly request state be de-allocated or request that some state be maintained if that's needed. S 7.1: This application does not seem very compelling to me. More likely is the VOD scenario or large (not small) broadcast examples where the server does not perform any crypto because that reduces server capacity for pumping out data or the server should not have the keys to the content (that is pre-encrypted). Also, the last sentence states that "security considerations...MUST be considered" but does not say exactly what they are. If they are security considerations from some other spec, I don't think that's MIKEYs business - the implementers need to comply with the other spec. S 7.2: Why can't DH be used and why can't multicast be used? S 8.1, 1st para: You don't state what size should be used but instead tell us what sizes are not appropriate. The I-D is unambiguous regarding the hash function in paragraph 3. S 8.2: I don't understand how it can be MIKEY's business to add MUSTs to specs that are already written. MIKEY is there to establish keys for security protocols and can give guidance on key usage. But if the spec for the data security protocol is broken, I don't see how you can mandate through MIKEY that it be fixed. S 8.3: Here is the 5-10 minutes point I mentioned above. Where does this come from? What is a "client?" What is a "very high load" of incoming calls? I think we need more of a model to understand the underlying process. S 8.6: I don't understand why this applies only to groups. S A: I don't think that this should be relegated to an appendix since the point of the spec is to define how to develop interoperable implementations. I'd move this into the body of the document. S A.1, next payload bullet: Is it admissible to have the header payload with no other payloads following it? S A.1, #CS: Are there a maximum 256 CSs or 255? How do you interpret 0? S A.1, CS ID map type: Why is this mandatory? Are you saying that if MIKEY is used to support some other data security protocol other than SRTP, then SRTP must there anyway? I think that mandatory-to-implement ensures interoperability, but requiring support for SRTP does not ensure MIKEY interoperability at all. S A.1.1: Why do we start at bit 16 rather than bit 0? Regarding Policy nr and SSRC x, does this correspond with #CS above. If so, is there a zero case corresponding to a #CS of zero? I assume that the src/dst addresses are coming from some other place than this payload. Also under the SSRC x bullet, I think that some point needs to be made about ensuring uniqueness and avoiding collisions. S A.2, 1st para: I had to search to find that "last payload" is defined in the table in A.1. S A.2, 3rd para: A graphic representation as done in IKE would be easier to follow. For example, you say that something MUST be added to the encrypted data but don't state the order. But you do give some idea of the ordering in fig 3.2. But fig 3.2 is more informative than normative since it is not a complete spec, merely expository. Again, I think I'd like to see the complete payload orderings given as in figures 3. S A.2, encr data bullet: What about KEKs? (though I think you should consider dropping re-key and then won't need to worry about KEKs). S A.4, DH key length bullet: Isn't this fully specified by DH-group? S A.4, KV bullet: You could adopt the new SRTP terminology of MKI. But if you want to support security protocols other than SRTP, then a generic name such as "SPI" might be more suitable. S A.5, 1st para: A graphical depiction of the payload flows as in figures 3 would help identify where this sig payload goes since you define a "last payload" value and state in the other payloads when to set the next payload to the "last payload" value but here you say that the sig payload is the last payload for certain messages. So I'm confused as to when the next payload is set to last payload (value 0) or to sig (value 4). S A.5: Where is the signature type declared? It seems that other payloads are self-announcing (e.g. the ID/cert payload), but this one is not. S A.6, next payload: so I assume that only in the pre-shared key case are we concerned with setting next payload to "last payload" (value 0) since in the other cases it would be set to the sig payload. S A.9: Is this only for the pre-shared key establishment procedure? S A.10.1, payload: Hmm, here's another that starts at bit 16. We should add an SRTCP encryption bit to signal the member to encrypt or not encrypt the SRTCP. S A.10.1, encr alg, auth alg: There are two notions of mandatory here. first is mandatory when SRTP is supported and the second is mandatory-to-implement for MIKEY. As I stated above, I think that nothing related to SRTP should be mandatory-to-implement for MIKEY. S A.10.1: for this item and maybe for some others, you may want to use type/length/value syntax rather than forcing everything to be specified. If you used TLVs, then it would be possible to let the encryption algorithm and key length default while specifying a non-default SRTP authentication algorithm or tag length. Also, TLVs are more extensible when you want to support other security protocols. It's not clear how you let some things default while overriding others. S A.10.2: do we really want to separate the SRTP from the SRTCP policy? This seems to be an unnecessary complication to me. S A.10.3: I think you should consider dropping re-key altogether. S A.13: When there are optional fields, I think that TLV syntax may be more appropriate. S A.13, KV bullet: I recall that you earlier stated that a lifetime is a MUST but there is a NULL option of no specific lifetime. Do you mean that Null indicates that the security protocol default is to be used. Also, the key validity period applies to the master key (PMK) in SRTP and not to a session key (TEK), right? S B: I find the tabular method of specifying message payload syntax to be hard to parse, maybe that's just because I'm accustomed to the more graphical representation of describing each message associated with an arrow (viz. figures 3) by listing the mandatory and optional payloads that compose the message. cheers, Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 2 03:49:45 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10167 for ; Tue, 2 Apr 2002 03:49:44 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1244153625; Tue, 2 Apr 2002 03:47:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id F0D3D535CE for ; Tue, 2 Apr 2002 03:46:26 -0500 (EST) Received: (qmail 23873 invoked by uid 3269); 2 Apr 2002 08:48:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23870 invoked from network); 2 Apr 2002 08:48:30 -0000 Received: from penguin-ext.wise.edt.ericsson.se (HELO penguin.wise.edt.ericsson.se) (193.180.251.34) by klesh.pair.com with SMTP; 2 Apr 2002 08:48:30 -0000 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g328mKs7019347 for ; Tue, 2 Apr 2002 10:48:20 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 02 10:42:12 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 10:31:59 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE4128@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Mark Baugher'" , jari.arkko@ericsson.com, "Elisabetta Carrara (ERA)" , =?iso-8859-1?Q?Mats_N=E4slund_=28ERA=29?= , "Karl Norrman (ERA)" Cc: msec@securemulticast.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] RE: comments on draft-ietf-msec-mikey-01.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 2 Apr 2002 10:41:32 +0200 Thanks Mark, Indeed, it seems to be a complete review (many thanks!). I will not try to answer all comments and questions (instead I will try to do that by considering them when I'm updating the draft). If there are any comments that you would like a quick answer on, just drop me another mail, and I'll try to do that. However, I have provided a few answers/comments on a few selected items (see below). > > I read the draft and have a number of comments. This looks > like a complete > draft. Glad to see that. I'll try to give a complete review. > > S 1.2: Why use "pre-master key" when there is no master key > or post-master > key used in the draft? The problem is that you tend to slip > into using > "master" to refer to the PMK as in section 4.1. The notation PMK is something that was used in the first version of the draft (when we still used the notation master key instead of TEK). So I think it might be time to change PMK to something else (e.g. master key). > S 4.1.3: I found use of "inkey" to be confusing. It's the > same as "s" > where you introduce the notation to be used in 4.1.2, isn't it? No. inkey = s_1 || ... || s_n (i.e. the inkey is split into n 512-bit blocks, and each block, s_x, is fed into P(s_x, seed, m) ) > S 6.1: A complete example would be reassuring. In fact, is > there to be a > reference implementation available sometime soon? We will (hopefully) start this week to update the current implementation so that it conforms to the current draft. > > S 6.3, last para: Would it make sense to select ANNOUNCE or > SET_PARAMETER > as the operation that tunnels the MIKEY message and say that > these are > mandatory to implement when MIKEY is used? It's clear that > some changes > are needed to the SIP or RTSP implementations (preceding note). Very good point. I was recommended at the meeting to do this by some RTSP people (i.e. the ANNOUNCE will be the mandatory). > S 6.4, last bullet: Is there any need or possibility for > carrying a MIKEY > "de-registration" or "tear-down" message? such a message > could explicitly > request state be de-allocated or request that some state be > maintained if > that's needed. Could be... But as long as SIP and RTSP is used, a kind of teardown will be done when the SIP/RTSP session is closed down. However, it may still be a good idea to include it to make it possible to have an explicit teardown. > S 7.2: Why can't DH be used and why can't multicast be used? Multicast can very well be used (that was more or less assumed, but unfortunately not explicitly stated). However, using a DH exchange will not make it possible to create the same TEK to two (or more) participant (this is because the TEK is generated from the DH-key). Therefore, the DH is not suitable for group communication. > S A.10.1: for this item and maybe for some others, you may > want to use > type/length/value syntax rather than forcing everything to be > specified. If you used TLVs, then it would be possible to let the > encryption algorithm and key length default while specifying > a non-default > SRTP authentication algorithm or tag length. Also, TLVs are more > extensible when you want to support other security protocols. > It's not > clear how you let some things default while overriding others. I agree, the TLV approach is probably better to use. > S A.10.3: I think you should consider dropping re-key altogether. Done. I brought the re-key stuff in to be "more" compliant to the GKMARCH, and to see if someone saw a need for it. If someone would see a need for it in the future, it would be possible to extend MIKEY with that. But so far, I have not seen any indications of the need for it (and both your and Martin's comments indicates that it may be worth to remove). We will continue to update the draft with more (and hopefully understandable) explanations. I think your review together with Martin's review have given us a quite good view of where to add more explanations. Thanks, Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Apr 5 10:24:42 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07276 for ; Fri, 5 Apr 2002 10:24:41 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0720753971; Fri, 5 Apr 2002 10:22:01 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8C6B6535AC for ; Fri, 5 Apr 2002 10:21:13 -0500 (EST) Received: (qmail 69898 invoked by uid 3269); 5 Apr 2002 15:23:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69894 invoked from network); 5 Apr 2002 15:23:23 -0000 Received: from p-mail2.rd.francetelecom.com (193.49.124.32) by klesh.pair.com with SMTP; 5 Apr 2002 15:23:23 -0000 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Fri, 5 Apr 2002 17:12:31 +0200 Message-ID: From: LANIEPCE Sylvie FTRD/DMI/CAE To: "'Ran Canetti'" , msec@securemulticast.org Subject: RE: [MSEC] new TESLA draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-378d0240-486b-11d6-b1ea-00508b69ab48" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 5 Apr 2002 17:12:31 +0200 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-378d0240-486b-11d6-b1ea-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCB4.4E984D80" ------_=_NextPart_001_01C1DCB4.4E984D80 Content-Type: text/plain Hi, Regarding Ran's TESLA layer placement question, here are some comments/questions (debate welcome): I was wondering about the relevance of a msec gateway. Basically, the msec gateway would operate as a boundary between an unsecured network (where the data coming from the source are protected by msec) and a safe network (an intranet for example, where fewer security protections are needed). Note that this scenario could be efficient in terms of key management, as the gateway could act in replacement of many receivers located within the safe network. So, in this case where data security treatments are externalized from the receivers, within a gateway, it seems to me that it would be better, for performance and cost reasons, to provide these security treatments at IP layer, instead of crossing all the gateway TCP/IP stack up to the application layer. I have the feeling (not that easy to demonstrate) that performing MSec treatments at IP layer is efficient if you opt for possibly externalized (from members, both sender and receiver) msec functionalities . This question probably goes with the relevance of outsourced msec functionalities (data treatment and also key management). On the source side, could msec perform some sort of traffic analysis protection (hiding source IP@ ?) if implemented at IP layer ? Are there any cases where application layer placement could give access to selectors not available at other lower layers, in order to apply different security treatments to different types of data within a given application ? Would TESLA be one source authentication solution among others for MESP/AMESP or would MESP/AMESP stick to TESLA ? Ran, I do not clearly understand why you mention a TCP hypothesis, since multicast goes with UDP. See TESLA draft, section 5 (drawbacks attached to TCP delays) ? I am not especially pushing hard IP layer placement, I am just letting you know what I can think about (and my analysis is probably (too much) influenced by the IPSec model, altought any AESP...). I am interested in considering, understanding and analyzing any argument in favour of an application layer placement. In addition, I am keen to look at msec also considering in details : - the security services msec can provide in real applications - the opportunities for an ISP to provide msec related functionalities in order to take into account their impacts (if any) on msec design. Any opinion on that subject ? Hope this helps Regards Sylvie France Telecom R&D - DMI/SIR -----Message d'origine----- De : Ran Canetti [mailto:canetti@watson.ibm.com] Envoye : samedi 2 mars 2002 16:08 A : msec@securemulticast.org Objet : [MSEC] new TESLA draft [Co-chair hat off] Folks, Please take a look at the following new I-D: http://search.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt It provides a general algorithmic/informational presentation of the TESLA source authentication mechanism. (This is an updated version of the irtf-smug draft from a year ago.) While you read, please keep in mind the following issue. Our planned next step is to write a standards-track draft describing how to implement TESLA in a specific scenario. The question is: how to go about it? In particular, should we first implement TESLA in the application layer or in the IP layer? There are advantages to each option (they are discussed in the draft). We would like to get the WG feedback on the draft in general and on this question in particular. Thanks, Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec ------_=_NextPart_001_01C1DCB4.4E984D80 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MSEC] new TESLA draft

Hi,

Regarding Ran's TESLA layer placement question, here = are some comments/questions (debate welcome):

I was wondering about the relevance of a msec = gateway. Basically, the msec gateway would operate as a boundary = between an unsecured network (where the data coming from the source are = protected by msec) and a safe network (an intranet for example, where = fewer security protections are needed). Note that this scenario could = be efficient in terms of key management, as the gateway could act in = replacement of many receivers located within the safe = network.

So, in this case where data security treatments are = externalized from the receivers, within a gateway, it seems to me that = it would be better, for performance and cost reasons, to provide these = security treatments at IP layer, instead of crossing all the gateway = TCP/IP stack up to the application layer.

I have the feeling (not that easy to demonstrate) = that performing MSec treatments at IP layer is efficient if you opt for = possibly externalized (from members, both sender and receiver) msec = functionalities . This question probably goes with the relevance of = outsourced msec functionalities (data treatment and also key = management).

On the source side, could msec perform some sort of = traffic analysis protection (hiding source IP@ ?) if implemented at IP = layer ?

Are there any cases where application layer placement = could give access to selectors not available at other lower layers, in = order to apply different security treatments to different types of data = within a given application ?

Would TESLA be one source authentication solution = among others for MESP/AMESP or would MESP/AMESP stick to TESLA ?

Ran, I do not clearly understand why you mention a = TCP hypothesis, since multicast goes with UDP. See TESLA draft, section = 5 (drawbacks attached to TCP delays) ?

I am not especially pushing hard IP layer placement, = I am just letting you know what I can think about (and my analysis is = probably (too much) influenced by the IPSec model, altought any = AESP...). I am interested in  considering, understanding and = analyzing any argument in favour of an application layer = placement.

In addition, I am keen to look at msec also = considering in details :
- the security services msec can provide in real = applications
- the opportunities for an ISP to provide msec = related functionalities
in order to take into account their impacts (if any) = on msec design. Any opinion on that subject ?

Hope this helps

Regards
Sylvie
France Telecom R&D - DMI/SIR

-----Message d'origine-----
De : Ran Canetti [mailto:canetti@watson.ibm.com= ]
Envoye : samedi 2 mars 2002 16:08
A : msec@securemulticast.org
Objet : [MSEC] new TESLA draft




[Co-chair hat off]

Folks,

Please take a look at the following new I-D:

http://search.ietf.org/internet-drafts/draft-perrig-ms= ec-tesla-intro-00.txt

It provides a general algorithmic/informational = presentation of the TESLA
source authentication mechanism. (This is an updated = version of the
irtf-smug draft from a year ago.)

While you read, please keep in mind the following = issue. Our planned next
step is to write a standards-track draft describing = how to implement
TESLA in a specific scenario. The question is: how = to go about it?
In particular, should we first implement TESLA in = the application layer
or in the IP layer? There are advantages to each = option (they are discussed
in the draft). We would like to get the WG feedback = on the draft in general
and on this question in particular.

Thanks,

Ran


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec

------_=_NextPart_001_01C1DCB4.4E984D80-- ------=_NextPartTM-000-378d0240-486b-11d6-b1ea-00508b69ab48-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Apr 5 11:55:51 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09680 for ; Fri, 5 Apr 2002 11:55:51 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C4E9053E19; Fri, 5 Apr 2002 11:52:03 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 573E453E02 for ; Fri, 5 Apr 2002 11:51:24 -0500 (EST) Received: (qmail 82394 invoked by uid 3269); 5 Apr 2002 16:53:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82391 invoked from network); 5 Apr 2002 16:53:35 -0000 Received: from softdnserror (HELO sj-msg-core-3.cisco.com) (171.70.157.152) by klesh.pair.com with SMTP; 5 Apr 2002 16:53:35 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g35GqCCl020135; Fri, 5 Apr 2002 08:52:12 -0800 (PST) Received: from mbaugher-w2k1.cisco.com ([10.34.251.92]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABJ14194; Fri, 5 Apr 2002 08:50:31 -0800 (PST) Message-Id: <4.3.2.7.2.20020405083028.0200e498@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: LANIEPCE Sylvie FTRD/DMI/CAE From: Mark Baugher Subject: RE: [MSEC] new TESLA draft Cc: "'Ran Canetti'" , msec@securemulticast.org, perrig@cs.berkeley.edu, dawnsong@cs.berkeley.edu, tygar@cs.berkeley.edu, bob.briscoe@bt.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3783870==_.ALT" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 05 Apr 2002 08:51:15 -0800 --=====================_3783870==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Ran is on extended travel and does not have regular Internet access. I think you are referring to draft-perrig-msec-tesla-intro-00.txt. I have copied the other authors on your note in case they are not receiving mail from msec. I'll take a swag at addressing your points below and invite the other authors to contribute as well. At 05:12 PM 4/5/2002 +0200, LANIEPCE Sylvie FTRD/DMI/CAE wrote: >Hi, > >Regarding Ran's TESLA layer placement question, here are some >comments/questions (debate welcome): > >I was wondering about the relevance of a msec gateway. Basically, the msec >gateway would operate as a boundary between an unsecured network (where >the data coming from the source are protected by msec) and a safe network >(an intranet for example, where fewer security protections are needed). >Note that this scenario could be efficient in terms of key management, as >the gateway could act in replacement of many receivers located within the >safe network. I have seen IP multicast configurations similar to this for satellite where the IP security serves a function that is analogous to a conditional access system that links, say, corporate networks to the satellite WAN. >So, in this case where data security treatments are externalized from the >receivers, within a gateway, it seems to me that it would be better, for >performance and cost reasons, to provide these security treatments at IP >layer, instead of crossing all the gateway TCP/IP stack up to the >application layer. Security is end-to-end and I think a better security solution is end-to-end rather than using what is essentially a firewall. A packet-filtering firewall typically operates on the IP or transport headers, but an application firewall operates at the application layer at the cost of increased complexity of the middle box. That being said, I understand your point but think that TESLA is better suited to the application layer since there is so much buffering that is needed. >I have the feeling (not that easy to demonstrate) that performing MSec >treatments at IP layer is efficient if you opt for possibly externalized >(from members, both sender and receiver) msec functionalities . This >question probably goes with the relevance of outsourced msec >functionalities (data treatment and also key management). I don't understand your points. >On the source side, could msec perform some sort of traffic analysis >protection (hiding source IP@ ?) if implemented at IP layer ? I think an IP-in-IP tunnel will do this. I think this is independent of the issue of putting TESLA in the IP layer. >Are there any cases where application layer placement could give access to >selectors not available at other lower layers, in order to apply different >security treatments to different types of data within a given application ? I can imagine, for example, using an RTP SSRC as a selector, which is not visible at the IP or transport layer. >Would TESLA be one source authentication solution among others for >MESP/AMESP or would MESP/AMESP stick to TESLA ? I believe this is so. >Ran, I do not clearly understand why you mention a TCP hypothesis, since >multicast goes with UDP. See TESLA draft, section 5 (drawbacks attached to >TCP delays) ? I don't know. Mark >I am not especially pushing hard IP layer placement, I am just letting you >know what I can think about (and my analysis is probably (too much) >influenced by the IPSec model, altought any AESP...). I am interested >in considering, understanding and analyzing any argument in favour of an >application layer placement. > >In addition, I am keen to look at msec also considering in details : >- the security services msec can provide in real applications >- the opportunities for an ISP to provide msec related functionalities >in order to take into account their impacts (if any) on msec design. Any >opinion on that subject ? > >Hope this helps > >Regards >Sylvie >France Telecom R&D - DMI/SIR > >-----Message d'origine----- >De : Ran Canetti >[mailto:canetti@watson.ibm.com] >Envoye : samedi 2 mars 2002 16:08 >A : msec@securemulticast.org >Objet : [MSEC] new TESLA draft > > > >[Co-chair hat off] > >Folks, > >Please take a look at the following new I-D: > >http://search.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt > > >It provides a general algorithmic/informational presentation of the TESLA >source authentication mechanism. (This is an updated version of the >irtf-smug draft from a year ago.) > >While you read, please keep in mind the following issue. Our planned next >step is to write a standards-track draft describing how to implement >TESLA in a specific scenario. The question is: how to go about it? >In particular, should we first implement TESLA in the application layer >or in the IP layer? There are advantages to each option (they are discussed >in the draft). We would like to get the WG feedback on the draft in general >and on this question in particular. > >Thanks, > >Ran > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec > --=====================_3783870==_.ALT Content-Type: text/html; charset="us-ascii" Ran is on extended travel and does not have regular Internet access.  I think you are referring to draft-perrig-msec-tesla-intro-00.txt.  I have copied the other authors on your note in case they are not receiving mail from msec.  I'll take a swag at addressing your points below and invite the other authors to contribute as well.

At 05:12 PM 4/5/2002 +0200, LANIEPCE Sylvie FTRD/DMI/CAE wrote:

Hi,

Regarding Ran's TESLA layer placement question, here are some comments/questions (debate welcome):

I was wondering about the relevance of a msec gateway. Basically, the msec gateway would operate as a boundary between an unsecured network (where the data coming from the source are protected by msec) and a safe network (an intranet for example, where fewer security protections are needed). Note that this scenario could be efficient in terms of key management, as the gateway could act in replacement of many receivers located within the safe network.

I have seen IP multicast configurations similar to this for satellite where the IP security serves a function that is analogous to a conditional access system that links, say, corporate networks to the satellite WAN. 


So, in this case where data security treatments are externalized from the receivers, within a gateway, it seems to me that it would be better, for performance and cost reasons, to provide these security treatments at IP layer, instead of crossing all the gateway TCP/IP stack up to the application layer.

Security is end-to-end and I think a better security solution is end-to-end rather than using what is essentially a firewall.  A packet-filtering firewall typically operates on the IP or transport headers, but an application firewall operates at the application layer at the cost of increased complexity of the middle box.  That being said, I understand your point but think that TESLA is better suited to the application layer since there is so much buffering that is needed.


I have the feeling (not that easy to demonstrate) that performing MSec treatments at IP layer is efficient if you opt for possibly externalized (from members, both sender and receiver) msec functionalities . This question probably goes with the relevance of outsourced msec functionalities (data treatment and also key management).

I don't understand your points.


On the source side, could msec perform some sort of traffic analysis protection (hiding source IP@ ?) if implemented at IP layer ?

I think an IP-in-IP tunnel will do this.  I think this is independent of the issue of putting TESLA in the IP layer.


Are there any cases where application layer placement could give access to selectors not available at other lower layers, in order to apply different security treatments to different types of data within a given application ?

I can imagine, for example, using an RTP SSRC as a selector, which is not visible at the IP or transport layer.


Would TESLA be one source authentication solution among others for MESP/AMESP or would MESP/AMESP stick to TESLA ?

I believe this is so.


Ran, I do not clearly understand why you mention a TCP hypothesis, since multicast goes with UDP. See TESLA draft, section 5 (drawbacks attached to TCP delays) ?

I don't know.

Mark


I am not especially pushing hard IP layer placement, I am just letting you know what I can think about (and my analysis is probably (too much) influenced by the IPSec model, altought any AESP...). I am interested in  considering, understanding and analyzing any argument in favour of an application layer placement.

In addition, I am keen to look at msec also considering in details :
- the security services msec can provide in real applications
- the opportunities for an ISP to provide msec related functionalities
in order to take into account their impacts (if any) on msec design. Any opinion on that subject ?

Hope this helps

Regards
Sylvie
France Telecom R&D - DMI/SIR

-----Message d'origine-----
De : Ran Canetti [mailto:canetti@watson.ibm.com]
Envoye : samedi 2 mars 2002 16:08
A : msec@securemulticast.org
Objet : [MSEC] new TESLA draft



[Co-chair hat off]

Folks,

Please take a look at the following new I-D:

http://search.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt

It provides a general algorithmic/informational presentation of the TESLA
source authentication mechanism. (This is an updated version of the
irtf-smug draft from a year ago.)

While you read, please keep in mind the following issue. Our planned next
step is to write a standards-track draft describing how to implement
TESLA in a specific scenario. The question is: how to go about it?
In particular, should we first implement TESLA in the application layer
or in the IP layer? There are advantages to each option (they are discussed
in the draft). We would like to get the WG feedback on the draft in general
and on this question in particular.

Thanks,

Ran

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec
--=====================_3783870==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Apr 5 13:48:29 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12980 for ; Fri, 5 Apr 2002 13:48:29 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3B1F553A43; Fri, 5 Apr 2002 13:44:29 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CB5C553E67 for ; Fri, 5 Apr 2002 13:43:26 -0500 (EST) Received: (qmail 96918 invoked by uid 3269); 5 Apr 2002 18:45:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96915 invoked from network); 5 Apr 2002 18:45:38 -0000 Received: from zcars04e.nortelnetworks.com (HELO zcars04e.ca.nortel.com) (47.129.242.56) by klesh.pair.com with SMTP; 5 Apr 2002 18:45:38 -0000 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35Iilw10374; Fri, 5 Apr 2002 13:44:47 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2C543DCP; Fri, 5 Apr 2002 13:44:47 -0500 Received: from nortelnetworks.com (192.32.225.110 [192.32.225.110]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2KA37T2Q; Fri, 5 Apr 2002 13:44:47 -0500 Message-ID: <3CADF2DB.7010200@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Mark Baugher Cc: LANIEPCE Sylvie FTRD/DMI/CAE , msec@securemulticast.org Subject: Re: [MSEC] new TESLA draft References: <4.3.2.7.2.20020405083028.0200e498@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 05 Apr 2002 13:54:19 -0500 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > > >> Would TESLA be one source authentication solution among others for >> MESP/AMESP or would MESP/AMESP stick to TESLA ? > > > I believe this is so. The first one! MESP/AMESP should support source authentication schemes other than TESLA as well. cheers, Lakshminath > > >> Ran, I do not clearly understand why you mention a TCP hypothesis, >> since multicast goes with UDP. See TESLA draft, section 5 (drawbacks >> attached to TCP delays) ? > > > I don't know. > > Mark > > >> I am not especially pushing hard IP layer placement, I am just >> letting you know what I can think about (and my analysis is probably >> (too much) influenced by the IPSec model, altought any AESP...). I am >> interested in considering, understanding and analyzing any argument >> in favour of an application layer placement. >> >> In addition, I am keen to look at msec also considering in details : >> - the security services msec can provide in real applications >> - the opportunities for an ISP to provide msec related functionalities >> in order to take into account their impacts (if any) on msec design. >> Any opinion on that subject ? >> >> Hope this helps >> >> Regards >> Sylvie >> France Telecom R&D - DMI/SIR >> >> -----Message d'origine----- >> De : Ran Canetti [ mailto:canetti@watson.ibm.com ] >> Envoye : samedi 2 mars 2002 16:08 >> A : msec@securemulticast.org >> Objet : [MSEC] new TESLA draft >> >> >> >> [Co-chair hat off] >> >> Folks, >> >> Please take a look at the following new I-D: >> >> http://search.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt >> >> >> It provides a general algorithmic/informational presentation of the TESLA >> source authentication mechanism. (This is an updated version of the >> irtf-smug draft from a year ago.) >> >> While you read, please keep in mind the following issue. Our planned next >> step is to write a standards-track draft describing how to implement >> TESLA in a specific scenario. The question is: how to go about it? >> In particular, should we first implement TESLA in the application layer >> or in the IP layer? There are advantages to each option (they are >> discussed >> in the draft). We would like to get the WG feedback on the draft in >> general >> and on this question in particular. >> >> Thanks, >> >> Ran >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Apr 5 13:52:45 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13087 for ; Fri, 5 Apr 2002 13:52:45 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 225B153E87; Fri, 5 Apr 2002 13:48:41 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3C4FF53E90 for ; Fri, 5 Apr 2002 13:47:44 -0500 (EST) Received: (qmail 97249 invoked by uid 3269); 5 Apr 2002 18:49:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97246 invoked from network); 5 Apr 2002 18:49:56 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 5 Apr 2002 18:49:56 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g35InBq6024544; Fri, 5 Apr 2002 10:49:11 -0800 (PST) Received: from mbaugher-w2k1.cisco.com ([10.34.251.92]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABJ17081; Fri, 5 Apr 2002 10:47:17 -0800 (PST) Message-Id: <4.3.2.7.2.20020405104714.04c6f4b0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] new TESLA draft Cc: LANIEPCE Sylvie FTRD/DMI/CAE , msec@securemulticast.org In-Reply-To: <3CADF2DB.7010200@nortelnetworks.com> References: <4.3.2.7.2.20020405083028.0200e498@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 05 Apr 2002 10:48:01 -0800 yes, I was unclear: A/MESP would of course support a variety of source authentication mechanisms. thanks, Mark At 01:54 PM 4/5/2002 -0500, Lakshminath Dondeti wrote: >Mark Baugher wrote: > >> >> >>>Would TESLA be one source authentication solution among others for >>>MESP/AMESP or would MESP/AMESP stick to TESLA ? >> >> >>I believe this is so. > > >The first one! MESP/AMESP should support source authentication schemes >other than TESLA as well. > >cheers, >Lakshminath > > >> >> >>>Ran, I do not clearly understand why you mention a TCP hypothesis, since >>>multicast goes with UDP. See TESLA draft, section 5 (drawbacks attached >>>to TCP delays) ? >> >> >>I don't know. >> >>Mark >> >> >>>I am not especially pushing hard IP layer placement, I am just letting >>>you know what I can think about (and my analysis is probably (too much) >>>influenced by the IPSec model, altought any AESP...). I am interested >>>in considering, understanding and analyzing any argument in favour of >>>an application layer placement. >>> >>>In addition, I am keen to look at msec also considering in details : >>>- the security services msec can provide in real applications >>>- the opportunities for an ISP to provide msec related functionalities >>>in order to take into account their impacts (if any) on msec design. Any >>>opinion on that subject ? >>> >>>Hope this helps >>> >>>Regards >>>Sylvie >>>France Telecom R&D - DMI/SIR >>> >>>-----Message d'origine----- >>>De : Ran Canetti [ mailto:canetti@watson.ibm.com ] >>>Envoye : samedi 2 mars 2002 16:08 >>>A : msec@securemulticast.org >>>Objet : [MSEC] new TESLA draft >>> >>> >>> >>>[Co-chair hat off] >>> >>>Folks, >>> >>>Please take a look at the following new I-D: >>> >>>http://search.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt >>> >>>It provides a general algorithmic/informational presentation of the TESLA >>>source authentication mechanism. (This is an updated version of the >>>irtf-smug draft from a year ago.) >>> >>>While you read, please keep in mind the following issue. Our planned next >>>step is to write a standards-track draft describing how to implement >>>TESLA in a specific scenario. The question is: how to go about it? >>>In particular, should we first implement TESLA in the application layer >>>or in the IP layer? There are advantages to each option (they are discussed >>>in the draft). We would like to get the WG feedback on the draft in general >>>and on this question in particular. >>> >>>Thanks, >>> >>>Ran >>> >>>_______________________________________________ >>>msec mailing list >>>msec@securemulticast.org >>>http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Apr 8 13:06:45 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00020 for ; Mon, 8 Apr 2002 13:06:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 78DAA53911; Mon, 8 Apr 2002 13:03:45 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 67EC8535B8 for ; Mon, 8 Apr 2002 12:58:27 -0400 (EDT) Received: (qmail 41919 invoked by uid 3269); 8 Apr 2002 17:00:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41916 invoked from network); 8 Apr 2002 17:00:45 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 8 Apr 2002 17:00:45 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g38GqsON016183; Mon, 8 Apr 2002 09:52:54 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com ([10.34.251.92]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABK25620; Mon, 8 Apr 2002 09:50:53 -0700 (PDT) Message-Id: <4.3.2.7.2.20020408094250.06c24ba8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: perrig@cs.berkeley.edu (Adrian Perrig) From: Mark Baugher Cc: msec@securemulticast.org, sylvie.laniepce@rd.francetelecom.com In-Reply-To: <20020408162253.396FB1CD0B0@paris.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: TESLA comments Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 08 Apr 2002 09:51:43 -0700 Hi Adrian I have a comment below. At 09:22 AM 4/8/2002 -0700, Adrian Perrig wrote: >Thanks Mark for addressing some of the issues, I am currently also >traveling. Below are additional comments. > > > So, in this case where data security treatments are externalized > > from the receivers, within a gateway, it seems to me that it would > > be better, for performance and cost reasons, to provide these > > security treatments at IP layer, instead of crossing all the gateway > > TCP/IP stack up to the application layer. > > > > Security is end-to-end and I think a better security solution is > > end-to-end rather than using what is essentially a firewall. A > > packet-filtering firewall typically operates on the IP or transport > > headers, but an application firewall operates at the application layer > > at the cost of increased complexity of the middle box. That being > > said, I understand your point but think that TESLA is better suited to > > the application layer since there is so much buffering that is needed. > >The buffering in the network layer is not much different from the >buffering that TCP performs (in the case a packet did not arrive, TCP >buffers subsequent data packets). I think we are in agreement that TESLA should not be performed at the IP layer, though perhaps at the transport layer. But I think that TESLA would be most useful in an SRTP or AMESP than it would be in AH or ESP. cheers, Mark > > Ran, I do not clearly understand why you mention a TCP hypothesis, > > since multicast goes with UDP. See TESLA draft, section 5 (drawbacks > > attached to TCP delays) ? > >TESLA can also be used in point-to-point authentication. A published >key of the TESLA keychain acts as a public key, which allows a >receiver to authenticate any subsequent packets (assuming synchronized >clocks). The advantage is that if N nodes in a network want to >authenticate their pairwise communication, you would need n*(n+1)/2 >shared keys, but if you use TESLA, you would only need to distribute n >public keys. > >So if you use TESLA to authenticate point-to-point TCP communication, >one should put TESLA in the network layer. > >Greetings, > Adrian _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 9 20:45:43 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26614 for ; Tue, 9 Apr 2002 20:45:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6BF5853BE5; Tue, 9 Apr 2002 20:42:35 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 18A435358D for ; Tue, 9 Apr 2002 20:40:56 -0400 (EDT) Received: (qmail 2552 invoked by uid 3269); 10 Apr 2002 00:43:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 2549 invoked from network); 10 Apr 2002 00:43:17 -0000 Received: from smtp011.mail.yahoo.com (216.136.173.31) by klesh.pair.com with SMTP; 10 Apr 2002 00:43:17 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Apr 2002 00:43:16 -0000 Message-Id: <5.0.0.25.2.20020409204252.019855d0@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org, gsec@lists.tislabs.com From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Slides from IETF53 are noew online (both GSEC and MSEC) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 09 Apr 2002 20:44:33 -0400 Folks, The slides from GSEC and MSEC at IETF53 (Minn) are now online at www.securemulticast.org. thomas ------ _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Apr 10 09:45:34 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19087 for ; Wed, 10 Apr 2002 09:45:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 68B0D53541; Wed, 10 Apr 2002 09:40:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 01E9453CB0 for ; Wed, 10 Apr 2002 09:39:06 -0400 (EDT) Received: (qmail 88794 invoked by uid 3269); 10 Apr 2002 13:41:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88789 invoked from network); 10 Apr 2002 13:41:28 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 10 Apr 2002 13:41:28 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3ADeBMY023243; Wed, 10 Apr 2002 06:40:11 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com ([10.34.251.92]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABK66643; Wed, 10 Apr 2002 06:38:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20020410063835.06f92970@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Thomas Hardjono From: Mark Baugher Cc: msec@securemulticast.org, gsec@lists.tislabs.com In-Reply-To: <5.0.0.25.2.20020409204252.019855d0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: [GSEC] Slides from IETF53 are noew online (both GSEC and MSEC) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Apr 2002 06:38:54 -0700 Thanks for doing this, Thomas At 08:44 PM 4/9/2002 -0400, Thomas Hardjono wrote: >Folks, > >The slides from GSEC and MSEC at IETF53 (Minn) are now online >at www.securemulticast.org. > >thomas >------ > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Apr 11 04:19:32 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22060 for ; Thu, 11 Apr 2002 04:19:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6851953DB4; Thu, 11 Apr 2002 04:15:51 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C468753BA1 for ; Thu, 11 Apr 2002 04:14:43 -0400 (EDT) Received: (qmail 53282 invoked by uid 3269); 11 Apr 2002 08:17:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53276 invoked from network); 11 Apr 2002 08:17:08 -0000 Received: from p-mail2.rd.francetelecom.com (193.49.124.32) by klesh.pair.com with SMTP; 11 Apr 2002 08:17:08 -0000 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Thu, 11 Apr 2002 10:16:13 +0200 Message-ID: From: LANIEPCE Sylvie FTRD/DMI/CAE To: "'perrig@cs.berkeley.edu'" Cc: msec@securemulticast.org Subject: [MSEC] draft-perrig-msec-tesla-intro-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-2ce177b2-4c7e-11d6-b1ea-00508b69ab48" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 11 Apr 2002 10:16:27 +0200 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-2ce177b2-4c7e-11d6-b1ea-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E131.2D8A22C8" ------_=_NextPart_001_01C1E131.2D8A22C8 Content-Type: text/plain Adrian, Thank you for your answers. Please, see in line. > I do not understand why there is no more need for the second security > condition defined in the TESLA SMUG draft (check that i is not an > interval in the future, i.e. i>>>>>>>>> To my understanding, the security condition you mention (the one described in section 4.5) describes a check to verify that the sender "is not yet in the interval during which it discloses the key K_i" used to calculate the M_j packet's MAC received by the client (xx); this second check (which is, I think, different from the one described in section 4.5) does not appear anymore in the MSEC TESLA draft and I was wondering why (this was my question, sorry I was unclear). <<<<<<<<< > Could you please add some comments about F(k)=f_k (0), F'(k)=f'_k(1) : 0 ? 1 ? This is a standard approach for generating two computationally indistinguishable values. The rationale is to use a cryptographic key in only one cryptographic operation. K_i is already used to derive K_{i-1}, so we don't want to use K_i also as the key for the MAC. >>>>>>>>>> That is explained in the draft and is OK. My question was referring more precisely about f_k(ZER0) and f'_k(ONE). But anyway, this point is not that important for me... forget it <<<<<<<<< Thank you again for your time Adrian. Thanks also to Bob and Mark for the layer placement discussion. Sylvie ------_=_NextPart_001_01C1E131.2D8A22C8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [MSEC] draft-perrig-msec-tesla-intro-00.txt

Adrian,
Thank you for your answers. Please, see in = line.

> I do not understand why there is no more need = for the second security
> condition defined in the TESLA SMUG draft = (check that i is not an
> interval in the future, i.e. = i<floor((t_j-t_0)/T_int))

Right. This check is useful for verifying a key, to = reduce the impact
of a DoS attack where the attacker floods the = receiver with random keys.
We do describe this check in the draft, look for the = following in
Section 4.5: x =3D floor((t_j - T_0) / T_int)

>>>>>>>>>>
To my understanding, the security condition you = mention (the one described in section 4.5) describes a check to verify = that the sender "is not yet in the interval during which it = discloses the key K_i" used to calculate the M_j packet's MAC = received by the client (x<i+d).

Apart from this check, the SMUG TESLA draft was = giving A SECOND security condition: to check that interval i is not in = the future (i>x); this second check (which is, I think, different = from the one described in section 4.5) does not appear anymore in the = MSEC TESLA draft and I was wondering why (this was my question, sorry I = was unclear).

<<<<<<<<<

> Could you please add some comments about = F(k)=3Df_k (0), F'(k)=3Df'_k(1) : 0 ? 1 ?

This is a standard approach for generating two = computationally
indistinguishable values. The rationale is to use a = cryptographic key
in only one cryptographic operation. K_i is already = used to derive
K_{i-1}, so we don't want to use K_i also as the key = for the MAC.

>>>>>>>>>>
That is explained in the draft and is OK. My = question was referring more precisely about f_k(ZER0) and f'_k(ONE). = But anyway, this point is not that important for me... forget = it

<<<<<<<<<

Thank you again for your time Adrian. Thanks also to = Bob and Mark for the layer placement discussion.

Sylvie

------_=_NextPart_001_01C1E131.2D8A22C8-- ------=_NextPartTM-000-2ce177b2-4c7e-11d6-b1ea-00508b69ab48-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec