From christer.holmberg@ericsson.com Fri Jun 1 00:39:41 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F0121F8624 for ; Fri, 1 Jun 2012 00:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+UfwgHW0xxW for ; Fri, 1 Jun 2012 00:39:41 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A55F721F8435 for ; Fri, 1 Jun 2012 00:39:40 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-e7-4fc871bb0693 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 15.7B.11869.BB178CF4; Fri, 1 Jun 2012 09:39:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 1 Jun 2012 09:39:30 +0200 From: Christer Holmberg To: Ben Campbell Date: Fri, 1 Jun 2012 09:39:27 +0200 Thread-Topic: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) Thread-Index: Ac0/XeHxC4Q8tjTmQwSQYpNsuYf2bQAa3BvQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C459A38F4@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> <2CDCC2EF-B5AF-4101-857C-0B9E42F381A8@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459128EF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C459A338F@ESESSCMS0356.eemea.ericsson.se> <5F1730E7-0C2D-49F1-8C8E-B5B065BABF90@nostrum.com> In-Reply-To: <5F1730E7-0C2D-49F1-8C8E-B5B065BABF90@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvre7uwhP+BqfemFjM7zzNbrH3cBeL xcKJ/1gdmD2WLPnJ5DFr5xMWjy+XP7MFMEdx2aSk5mSWpRbp2yVwZVy4O5mp4Bp3xZZFP9ga GDdydjFyckgImEhcPHGBCcIWk7hwbz1bFyMXh5DAKUaJxtlPWSCcBYwSb/Y9ZO5i5OBgE7CQ 6P6nDdIgIqAk8bx5K1gNs0Abo8Ssvg8sIAkWARWJNZsOM4PYwgKpErO2bmGBaEiT6F60jhnC NpLYfKqNHcTmFQiXeDLzONTmScwSt+9+YgRJcArYS2xb3sAGYjMCnff91BqwU5kFxCVuPZkP dbaAxJI955khbFGJl4//sULUi0rcaV/PCFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwW krGzkLTMQtIyC0nLAkaWVYzCuYmZOenlRnqpRZnJxcX5eXrFqZsYgTF1cMtv1R2Md86JHGKU 5mBREue13rrHX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj231Guz55toWdU/bNdfHsfnjj lkHmFsYNYimSBQdlnF9ta7D8O9n5sMpxA+bTLSq9ZufnG/c8rnxbu0kr/xXXvJyUnr7VfVOu 98617zkqean/+36vMC/+uLp5oSKS29ZPrHwtMX3G8v1Cgr+11NSYo+4x3TfYWelU8ubsZ+W5 nzN9DrobJ+xQYinOSDTUYi4qTgQAY38WiXcCAAA= Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 07:39:41 -0000 Hi, =20 >>> I don't think the definition needs to describe the entire process. coul= d we just say "name of the peer", perhaps with a disclaimer that that the m= eaning of "name" is as described by the protocol? >>=20 >> So, something like: >>=20 >>=20 >> "Name Based Authentication: An authentication method in which an=20 >> endpoint receives an X.509 certificate from its peer as part of the=20 >> TLS authentication. The endpoint validates that a chain of issuers exis= ts=20 >> from the certificate to a trusted certification authority, and that the= =20 >> certificate contains the name (as indicated in SIP/SDP) of the=20 >> peer." >>=20 >>=20 > > Works for me. Actually, we noted that the suggested text does not take RFC 6072 into cons= ideration. So, what about: "Name Based Authentication: An authentication method in which an=20 endpoint receives an X.509 certificate from its peer as part of the=20 TLS authentication. The endpoint verifies that the identity associated=20 with the certificate corresponds to that of the peer (as indicated in SIP/= SDP)=20 and that the binding of the identity to the public key was done by a party= which the endpoint trusts. This definition includes both traditional certificates is= sued by a=20 well-known certification authority as well as self-signed certificates pub= lished via=20 a SIP Certificate Management Service [RFC6072] and other similar mechanism= s." Regards, Christer From eburger@standardstrack.com Fri Jun 1 03:47:27 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021CA21F861F for ; Fri, 1 Jun 2012 03:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGaNAvPX9mHh for ; Fri, 1 Jun 2012 03:47:24 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id D644D21F85E4 for ; Fri, 1 Jun 2012 03:47:24 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:53537 helo=[192.168.15.135]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SaPO7-0007Sv-4X; Fri, 01 Jun 2012 03:47:23 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Burger In-Reply-To: <8B33C1AA-3B30-413B-834C-2BFFF152E79D@nostrum.com> Date: Fri, 1 Jun 2012 06:47:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0CFA@ESESSCMS0356.eemea.ericsson.se> <7B321302-CDFC-4966-9928-CCB202E33AAC@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459128EE@ESESSCMS0356.eemea.ericsson.se> <8B33C1AA-3B30-413B-834C-2BFFF152E79D@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 10:47:27 -0000 But, without CEMA you have no possibility of end-to-end encryption. At = least with CEMA you have the possibility. On May 29, 2012, at 6:17 PM, Ben Campbell wrote: > (Apologies for the heavy quoting) >=20 > On May 28, 2012, at 2:19 AM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >>>>> -- 7.1, and general: >>>>>=20 >>>>> I'm still uncomfortable with the language that says (or >>>>> implies) that CEMA enables e2e security in general. In fact, it >>>>> enables it in a some very specific use cases, namely when you have >>>>> middleboxes that behave exactly as described in this document--in >>>>> particular, when they transparently forward TLS, _and_ where = direct >>>>> e2e TLS connections are prevented by some aspect of the provider's >>>>> architecture (e.g. the middlebox use is required by policy, e2e >>>>> connections are prevented by NATs, etc.) >>>>=20 >>>> In my opinion, the text in section 7.1 is quite clear on this: >>>>=20 >>>> "In deployments where Middleboxes are always used, >>>> which is the main use case for the CEMA extension, the CEMA = extension >>>> increases the security by enabling the use of end-to-end = TLS between the two >>>> endpoints." >>>=20 >>> Okay, I see that you constrained the benefit to the case where >>> "Middleboxes are always used". The problem I still have is, these >>> middleboxes may or may not choose to allow an e2e security >>> association. And as far as I can tell, without adding some other = layer >>> of e2e security, the endpoints have no way of knowing if the SA is = e2e >>> or hop-by-hop (and that's really only for the first hop, as the >>> endpoint can't know what a middlebox does for downstream hops.) = Since >>> the middleboxes are not standardized devices, we can't even point to >>> normative language indicating that they SHOULD tunnel TLS. >>>=20 >>> I 'd argue that if an endpoint can't be reasonably sure it has an = e2e >>> SA, then it doesn't. And I suspect that, in practice, a lot of these >>> middleboxes are going to be there for reasons other than just = firewall >>> and NAT traversal. If any of those reasons require access to = cleartext >>> (and they almost certainly will), then the middlebox is never going = to >>> just tunnel TLS. >>>=20 >>> Keep in mind this draft is about _endpoint_ behavior, and the = security >>> considerations are from the endpoint's perspective. >>> I think, from the endpoint's perspective, the assertion that CEMA >>> enables e2e TLS is overstated, unless we are very explicit about = what >>> sort of assumptions the endpoint might make. So I'd like to see this >>> change to something to the effect of the following: >>>=20 >>> "CEMA enables middleboxes to allow end-to-end TLS security >>> considerations in some cases. MIddleboxes may or may not allow >>> end-to-send SAs, as a matter of local policy. Therefore a CEMA >>> endpoint MUST NOT assume that it has an end-to-end SA with it's peer >>> unless it can confirm this using some other mechanism", perhaps with = a >>> reference to the section(s) discussing some potential methods for >>> that. >>=20 >> I am happy to add text, as long as it doesn't give the impression = that CEMA somehow lowers >> security. An MSRP endpoint - CEMA enabled or not - should never = assume that it has an end-to-end SA >> with it's peer unless it can confirm this using some other mechanism. >=20 > I agree, and don't mean to say that CEMA lowers security compared to = the _same_topology_ without CEMA. But I do think the use of middleboxes = is likely to lower security compared to true e2e usage. That's why I = have trouble with text suggesting CEMA improves security in _general_. = It _may_ improve security in some very specific cases. >=20 > Arguably, there are issues with RFC4976 relays as well, since they = don't support e2e crypto at all. But at least they are visible to the = endpoints, at least one of which must choose to use them. Other = techniques such as TURN-TCP could be even better. >=20 >>=20 >>> I think I mentioned that it would be nice to see the security >>> considerations opening with a discussion of trust implications and >>> what assumptions an endpoint might make. >>> This sort of thing might go there. >>=20 >> How would it be any different from legacy, non-CEMA, MSRP? >>=20 >> A signalling proxy will always be able to insert a covert middlebox = and intercept the traffic as long as the key management technique used = depends on trusted signalling. >=20 > It's explicitly incompatible with e2e protection. >=20 > I think this points out a potential point of language confusion, = around the idea of trusting the signaling channel. When I say I trust = the signaling channel, I mean that there are mechanisms in place to = prevent an intermediary from changing the SDP without my knowing about = it. When you say it, I think you mean that you are allowing middleboxes = to change the SDP, but you trust them to use their powers only for good. = And that goes for the other guy's middleboxes as well. >=20 > hen you enable CEMA, you are assuming the second case. That by itself = has security implications that should be discussed. It's mentioned in = several places in the draft, but I think it would useful to have a few = paragraphs at the beginning of the security considerations that discuss = it from an explicit security perspective. >=20 >>=20 >>=20 >> ------------- >>=20 >>=20 >>>>> But even then, the fact that the endpoints have no way of telling >>>>> whether the middlebox actually tunnels TLS vs acting as a >>>>> TLS b2bua makes me very skeptical of any claim of enabling e2e = protection. I >>>>> think that, if the endpoints can't _prove_ the protection is e2e, >>>>> then it has to assume that it is _not_ e2e. >>>>=20 >>>> True end-to-end security requires a key management protocol >>>> that does not depend on secure signalling, e.g. name based >>>> certificates. >>>=20 >>> I do not understand that assertion. Why would a key management >>> protocol that requires trusted signaling not be end to end, assuming >>> you have trusted signaling? I understand that you pretty much can't >>> have trusted signaling over the sorts of middleboxes CEMA >>> contemplates, but that's not the same thing. >>=20 >> Assume fingeprint based key managment. If the signalling is trusted = then by definition the fingerprints won't be modified >> along the signalling path. Regardless of whether CEMA is used and = middleboxes are inserted, the TLS tunnel has to be >> end-to-end or else there will be a certificate mismatch. >>=20 >> OTOH, if the signalling is not trusted and the fingerprints and the = rest of the SDP can be modified, then a covert middlebox >> that terminates the TLS tunnel can be inserted regardless of whether = CEMA is used or not. The only difference between the >> CEMA and the non-CEMA case is that in the latter case the middlebox = has to modify the URLs in the MSRP messages. >>=20 >> I don't understand what it meant by "proving" that the protection is = end-to-end. As long as you rely on secure signalling you (as an = end-user) can never verify that the TLS tunnel is end-to-end. >=20 > I think we are talking past each other somewhere, because in my mind = CEMA does not perform its purpose, in the sense that it adds no value, = unless the middleboxes can modify the SDP. That's where the fingerprints = live, right? >=20 > See my previous comment about "trusted signaling", because I think we = are interpreting it in contradictory ways. >=20 >>=20 >>=20 >> ------------- >>=20 >>=20 >>>> Whether such a protocol (together with the necessary >>>> infrastructure) is available or not is a deployment issue, and is >>>> independent of CEMA. >>>>=20 >>>> The statement that CEMA enables end-to-end security is true >>>> under following conditions: >>>>=20 >>>> (1) The deployment is such that it requires the use of Middleboxes; >>>> and >>>>=20 >>>> (2) A key management protocol is available that does not depend on >>>> secure signalling. >>>>=20 >>>> In my opinion the text is quite clear on the above. >>>=20 >>> I don't think it is unclear per se, I just don't think it provides >>> enough discussion for (potentially naive) implementers to fully >>> understand the implications of their choices. So, here's some >>> suggested text: >>>=20 >>> "The purpose of CEMA is to enable communication over middleboxes. >>> These middleboxes are commonly deployed by SIP network operators, = who >>> also commonly deploy firewall and routing policies that prevent = media >>> sessions from working unless they traverse the middleboxes. = Endpoints >>> that are not willing to trust such middleboxes SHOULD NOT enable = CEMA. >>>=20 >>> CEMA makes it possible for middleboxes to tunnel TLS to allow >>> end-to-end security associations between endpoints. This is an >>> improvement over the status quo, since without CEMA, the middleboxes >>> would be forced to both read and modify the cleartext MSRP messages, >>> which would make end-to-end confidentiality and integrity protection >>> impossible. However, middleboxes may still choose to act as TLS >>> B2BUAs, which would be undetected by endpoints unless they use some >>> additional mechanism to authenticate that the TLS SA is in fact >>> end-to-end. Endpoints enabling CEMA MUST NOT assume end-to-end TLS >>> protection of an MSRP without such a mechanism. >>>=20 >>> Since the middleboxes described in this draft operate by modifying = the >>> contents of SDP offers and answers, mechanisms that depend on >>> end-to-end integrity or confidentiality protection of the SIP = message >>> payloads will fail. Therefore, endpoints using CEMA need to use a = key >>> management or authentication mechanisms that does not require >>> end-to-end trust in the SIP signaling channel. Section [xxx] = discusses >>> some such mechanisms. >>>=20 >>> >>> These are issues are not specific to CEMA, as the same issues occur >>> when using middleboxes without CEMA. Security mechanisms that = provide >>> end-to-end protection of SIP message payloads, such as RFC 4744 >>> [informational reference], will detect the fact that an intermediary >>> modified the payloads. >>> Such mechanisms cannot distinguish between an authorized middlebox = and >>> a man-in-the-middle attacker. But since CEMA is specifically = intended >>> for use with middleboxes, CEMA implementors should carefully = consider >>> the trust implications. >>> " >>=20 >> As you do mention in the last paragraph, these issues are not = specific to CEMA-enabled MSRP endpoints. Again, as long as the key = exchange >> depends on secure signalling (such as fingerprint based certificate = verification) it is always possible to insert a middlebox and terminate = the >> TLS tunnel, regardless of whether the endpoints support CEMA or not. >=20 > I agree that those things are true, but I think they are things an = implementer (and a user) of CEMA needs to think about. Maybe = implementers of SIP and MSRP in general should think about them too, but = the security considerations of those specs are not under discussion here = :-) >=20 >>=20 >> I don't entirely agree with the final paragraph since I find the = usefulness of RFC 4744 slighlty exagerrated. Assume that an MSRP session = is >> being established from A to B and that AS_A and AS_B are the RFC 4744 = Authentication Service for user A and user B, respectively. AS_* and P = are SIP proxies. >>=20 >> A <--> P <--> P <--> AS_A <--> P <--> P <--> AS_B <--> P <--> P <--> = B >>=20 >> There is no way for user A to know whether the TLS tunnel is really = end-to-end since it cannot be certain that any of the proxies in the = start/end of the >> path hasn't modified the fingerprint and the c and m lines in the = offer/answer SDP. >>=20 >> Even if RFC 4744 was extended to allow for signing parts of the SDP I = don't think it would greatly improve security. The user would still be >> required to trust some of the signalling nodes. >=20 > I accept that RFC4744 can be used in insecure ways. That's true of = most security mechanisms. I think it can also be used in reasonably = secure ways. But in any case, I listed it as an example, and would be = happy to have it removed, or replaced with some other similar example. >=20 >>=20 >>=20 >> ------------- >>=20 >>=20 >>>>> -- 7.1, last sentence "If the key management depends on >>>>> trust in the >>>>> signaling plane, the Middlebox is by definition trusted, but the >>>>> security is still increased as the cleartext is not >>>>> available in the Middlebox." >>>>>=20 >>>>> The first half of that sentence needs elaboration, particular in >>>>> light of the other assertions that fingerprint based >>>>> authentication implies trust in the signaling plane. Are you = talking about trust >>>>> that the signaling plane authentication of endpoints is in >>>>> fact true, or trust in whether the offer/answer has not been = tampered >>>>> with? It seems to me that something like RFC4474 can use = fingerprint >>>>> authentication of the media session with at least minimal trust in = middleboxes. >>>>>=20 >>>>> I think it would help to open the security considerations section >>>>> with a subsection that explains the trust assumptions for CEMA in >>>>> more detail >>>>=20 >>>> It's actually both. If self-signed certificates is to be >>>> considered secure then both endpoints and the intermediate >>>> nodes must be authenticated and the fingerprint attribute >>>> cannot be tampered with by the intermediaries. >>>=20 >>> The sentence in question starts with "If key management >>> depends on trust in the signaling plane...". But aren't we >>> saying that the key management mechanism used with CEMA >>> _cannot_ depend on trust in the signaling plane? Or by "trust >>> in the signaling plane" do we mean trusting that the >>> middleboxes will only use their powers for good? >>=20 >> In my opinion, "trust in the signalling plane" means that the service = provider can access the media if it wants to (but no one else) and the >> user accepts this. I don't see why this definition would change when = CEMA is introduced. >=20 > See my previous comment on the subject. I guess it's a question of = trusting the _channel_ vs the _network_. >=20 >>=20 >>> There's probably a place for a level of trust that means >>> something like "I trust that only the phone company and maybe >>> the government can see my cleartext messages", for which just >>> using SIPS may be good enough. That's not that different from >>> the current status with SMS/MMS. But it's _very_ different >>> than an assumption of end-to-end message confidentiality. >>=20 >> I don't see how this is related to CEMA. >=20 > Again, while it may apply to non CEMA cases, it's important for CEMA = implementers to understand it. >=20 >>=20 >>>> I do agree that, if RFC 4474 is used, then it is not >>>> necessary to trust all the intermediate nodes. However, RFC >>>> 4474 would not work well together with media anchoring since >>>> the entire SIP body is signed, which means that the c/m lines >>>> can't be modified. >>>=20 >>> Right. I guess the point is (and I hope my proposed text >>> above covers it), is that, in order to assume e2e TLS >>> protection of the MSRP channel in the presence of >>> middleboxes, you have to use an authentication/key-binding >>> mechanism that doesn't break when the middleboxes tamper with the = SDP. >>=20 >> Yes. >>=20 >>=20 >> ------------- >>=20 >>=20 >>>>> -- 7.4, 2nd paragraph: "This can e.g. be hop-by-hop cryptographic >>>>> protection or cryptographic access protection combined >>>>> with physical trust in other parts of the signaling plane." >>>>>=20 >>>>> I'm not sure what you intend by this sentence. Should I >>>>> infer that a hard shell soft center model of protection is good = enough? >>>>> What are the trust implications for hop by hop? What do you mean = by access >>>>> protection? >>>>>=20 >>>>> It seems like the real point is you _can't_ use end to end >>>>> integrity protection for signaling across middleboxes, with or = without CEMA. >>>>=20 >>>> If you want to use fingerprint based authentication then >>>> you have to somehow ensure yourself that the fingerprint >>>> attributes won't be manipulated by intermediate nodes. >>>>=20 >>>> That can be accomplished in many different ways, but it is >>>> completely independent of the use of CEMA. I therefore think >>>> the current level of detail is sufficient. >>>>=20 >>>> Access protection means that the signalling from the user >>>> to the first SIP Proxy is protected by TLS (i.e. SIPS), >>>> IPsec, or by some other means (e.g., encryption and integrity >>>> protection of the air interface in 3G/4G). >>>>=20 >>>> The trust implications of using hop-by-hop security and >>>> fingerprint based authentication are as explained in RFC 5763 >>>> (see especially Section 8.2). >>>=20 >>> My objection was specifically to the idea of "physical >>> trust". If that means something like IPSec, then great. If it >>> means I trust that that the network is in a locked room, then >>> any such assertion needs lots of disclaimers that this is not >>> the general case. >>=20 >> It is up to the service provider to make sure the core network is = sufficiently protected. This involves securing the physical nodes as = well >> as the links between them. How this is accomplished is a deployment = issue. You could put the all the nodes in a single locked room or >> you have the nodes in separate locked rooms and use IPSec or TLS in = between. Physical security is always an issue but it is often not >> mentioned. >=20 > I think this is a definition issue. I think of "physical security" to = mean doors and locks. IPSec and TLS are not physical security by that = definition. I'm not sure if that's the _correct_ definition, but if = there is one that includes crypto techniques, it would be good to = reference it or define it. >=20 >=20 >>=20 >>=20 >> ------------- >>=20 >>=20 >>>>> -- 7.4, 3rd and 4th paragraphs: >>>>>=20 >>>>> How can a user determine which case (e2e TLS vs TLS b2bua) is in >>>>> effect, and decide whether to allow it? >>>>=20 >>>> If fingerprint based authentication is used, then it is not >>>> possible for the user to determine whether the TLS connection >>>> is end-to-end or terminated by a B2BUA. >>>>=20 >>>> If this is required by the user then he has to use some >>>> other key management protocol. >>>>=20 >>>> Whether this is possible or not is an >>>> implementation/deployment issue. >>>=20 >>> I hope my comment here will become moot based on the larger >>> discussion of the first two items. >>=20 >>=20 >> I think my answer still holds. The only restriction in the choice of = key management protocol is that it must be possible for an intermediate = signalling proxy to modify the c/m lines. >=20 > Again, I see this as a detail of the larger arguments above--let's see = how those shake out. >=20 >>=20 >>=20 >> ------------- >>=20 >>=20 >>>>> -- 7.4, last paragraph: "But this is not an issue as the signaling >>>>> network is considered trusted by the endpoint (a >>>>> requirement to use fingerprint based authentication)." >>>>>=20 >>>>> I don't think I accept that statement in general. (see previous >>>>> comment for 7.1 about trust in middleboxes) >>>>=20 >>>> See my reply on your comment on section 7.1. >>>>=20 >>>> The statement is true for fingerprint based authentication >>>> without RFC 4474. If RFC 4474 is used then you only need to >>>> trust parts of the signaling network, but you won't be able >>>> to do media anchoring (the main purpose of CEMA). >>>=20 >>> For a fingerprint based mechanism without integrity >>> protection, I agree with you. But the sentence states it as >>> if were true in general. In any case, it seems like this >>> section says something like "You can't do fingerprint based >>> key management unless you trust the network, since you can't >>> integrity protect the SDP across middleboxes. But that's not >>> a problem, because you if you wanted to do fingerprints, you >>> must already trust the network." If that's what you mean, >>> then it's a circular argument. >>>=20 >>> I _think_ the point is really along the lines of "Even though >>> you can't integrity-protect your fingerprints across >>> middleboxes, the fingerprint across may be better than >>> nothing. If you are willing to trust the (possibly both) >>> service providers, you can reasonably be sure no malicious >>> third parties can mess with your fingerprints by using SIPS." >>>=20 >>> But that's still very different from e2e media protection. >>>=20 >>> (Your previous mention of RFC5763 might be relevant here, as >>> I think we're trying to say the same thing it did). >>=20 >> But, isn't the sentence true in general? Currently the only way of = integrity protecting fingerprint is via SIPS, RFC 4474, or S/MIME. Both = SIPS and RFC 4474 >> requires that the signalling network is trusted (at least parts of = it). End-to-end S/MIME requires client certificates and if you have that = you >> wouldn't use fingerprints to begin with (or they are still used but = they have no purpose). >>=20 >> To me at least, "fingerprint based authentication" without any = further precision implies that the signalling network is trusted. >=20 > Trust of the "network" is not an all or nothing thing, and I think = that is the crux of our disagreements. Trusting an identity service is a = very different thing than trusting a middlebox. There may be cases where = one or both are reasonable, but they are still different animals. This = is partly the basis of my request for a more detailed discussion about = trust assumptions. Rather than say you must "trust the signaling" plane, = let's talk about what elements you trust for what purposes. >=20 >>=20 >>=20 >> ------------- >>=20 >>=20 >>>>> I think the way this is being presented involves some dog-wagging. >>>>> It's not so much that the end user wants to trust the >>>>> middleboxes as much as it is an operator that won't let calls = complete if >>>>> they don't anchor on a middlebox. This is a fairly coercive >>>>> definition of trust. >>>>=20 >>>> I don't think you ever *want* to trust anyone. >>>>=20 >>>> The user has to make a decision whether he thinks the benefits of >>>> using the service outweighs the associated risk. If the >>>> answer is yes, then he trusts the service provider. >>>=20 >>> I doubt the average user is aware he needs to make such a >>> decision, much less competent to make it. And in many cases, >>> the user may have no choice in the matter, other than to >>> carefully watch what they say over the media channel. (But I >>> hope this concern is covered in my proposed text early in this = email.) >>>=20 >>> The bigger issue is that the user may not have enough >>> information to make informed trust decisions. The user does >>> not know if middleboxes are going to be used or not, or what >>> policies the middleboxes might have. If he cares, he needs to >>> take the aforementioned steps to ensure (or at least detect >>> the lack of) e2e media protection. >>>=20 >>> That all being said, I would be okay with this section if it >>> clarified what it means to trust the network. I think in this >>> case, it means the user understands that the service provider >>> has access to and can modify the cleartext of his messages, >>> and trusts the provider not to do anything inappropriate. >>> This may be sufficient for normal, day-to-day communication, >>> but might not be sufficient for banking, medical information, >>> trade secrets, etc. >>=20 >> In some cases the user would be able to control this via his UA. He = could configure the UA to only use a specific key management >> protocol and reject all others. But of course the service provider = could choose to reject such clients. >>=20 >> I think your definition of "trust in the signalling network" sounds = good and is reasonable. >>=20 >>>> In some cases it is not possible to setup a call without >>>> inserting a Middlebox (e.g. IPv4 user to IPv6 user). One could try = to determine >>>> when an end-to-end TCP connection can be established but >>>> that is often complex. >>>=20 >>> There are a number of approaches to that other than using >>> middleboxes. If a session can't be set up without a >>> middlebox, it's because the service provider chose to make it >>> so. The real problem with middleboxes is that they are, or at >>> least try to be, invisible to endpoints. >>=20 >> If the other choices were easier/cheaper than I would assume that the = service provider would implement them. If all the service provider >> wants is to be able to interecept the traffic, then there are other = ways of doing that as well. >>=20 >>=20 >=20 > Okay, I guess. I think the real answer is that the operator often has = requirements that go well beyond NAT/Firewall traversal. >=20 >> ------------- >>=20 >>=20 >>>>> -- 7.5, 2nd to last paragraph: "Alternate key distribution >>>>> mechanisms...may become ubiquitous enough to solve the key >>>>> distribution problem in the future." >>>>>=20 >>>>> Do we believe RFC 6072 is that ubiquitous _now_? This seems like a >>>>> dodge to avoid a normative downref. If so, lets not hide it behind >>>>> "ubiquity". Perhaps the text should read "may become sufficiently >>>>> standardized..." >>>>=20 >>>> The lack of standards is not always the problem. It's also >>>> about deployment. >>>>=20 >>>> So, we could say: "sufficiently standardized and deployed" >>>=20 >>> I'm not sure you get my point. Do you believe RFC 6072 is >>> sufficiently deployed? More deployed than the other choices? >>=20 >> I have no idea of how widely deployed RFC 6072, I don't even know who = could provide such information. The current text is based >> on feedback and discussions with the security area ADs. >=20 > Hopefully one or more of them will read this, and comment on this = specific point. Again, my concern is that we don't use sleight-of-hand = to avoid a normative downref. We we need one, we should go through the = process to get one. If we really don't, then I'm fine with it. >=20 >>=20 >>=20 >>=20 >> ------------- >>=20 >>=20 >>>>> -- 7.5, last paragraph: "Some of these options require >>>>> trusting the service provider, but those issues are beyond the = scope of this >>>>> document." >>>>>=20 >>>>> Isn't this entire document predicated on the idea of endpoints >>>>> trusting the provider? >>>>=20 >>>> Whether the service provider needs to be trusted or not depends on = the >>>> chosen key management, and this is entirely independent of CEMA. >>>=20 >>> Not really, since you use CEMA because you expect >>> middleboxes, and the presence of middleboxes constrains our >>> key-management mechanisms to things that don't use e2e >>> integrity protection of the SDP. A lot of this discussion so >>> far has been about that very point. >>=20 >> The only way of integrity protecting the SDP end-to-end that I know = of is S/MIME which requires client certificates. But if you have >> client certificates then you might as well use them directly in the = TLS handshake. See my earlier comments regarding RFC 4474. >=20 > I think this is another detail of the larger arguments above. >=20 >>=20 >>=20 >> ------------- >>=20 >>=20 >>>>> -- 7.7, 3rd paragraph: "Signaling over a local or closed >>>>> network MAY be trusted." >>>>>=20 >>>>> That's a broad statement to make without a considerably longer and >>>>> more nuanced discussion. As it stands, it seems to encourage a >>>>> hard-shell-gooey-center approach to security. >>>>=20 >>>> Yes, you're right that this is an imprecise statement. >>>>=20 >>>> But I don't understand why we should describe it further in this >>>> document. Again, the selection of key management protocol and the >>>> restrictions it imposes is independent of CEMA. >>>=20 >>> A normative "MAY" implies some degree of approval. Assuming a >>> network is secure because it's somehow locked away from the >>> rest of the world is dangerous. Disgruntled employees with >>> "secure" network access are the source of a great many >>> security failures. We may recognize that many carriers and >>> SDOs choose to depend on physical security alone. That >>> doesn't mean we should suggest it. >>=20 >> Perhaps we should change the "MAY" to a non-normative "may". >=20 > I'm okay with it, although it might be better to avoid the confusion = of a non-normative "may". Perhaps something along the lines of "might?" >=20 >>=20 >>=20 >> ------------- >>=20 >>=20 >>>>> -- 7.7, 4th paragraph: "It should however be noted that using >>>>> fingerprint based authentication over an insecure network >>>>> increases the security compared to unencrypted MSRP as this makes = it >>>>> harder to perform an man-in-the-middle attack." >>>>>=20 >>>>> You don't even need a MiTM attack if MSRP is used without >>>>> protection >>>>=20 >>>> I disagree. >>>>=20 >>>> Even if unencrypted MSRP is used, the attacker still need >>>> to intercept the traffic somehow. This means that you have some = level of >>>> security (the level depends on the network you're on). >>>=20 >>> That's not necessarily MiTM. With unprotected MSRP, you are >>> vulnerable to passive attacks as well. >>=20 >> That's a matter of definition. AFAIK a MitM attack can be both = passive and active. What passive really means can also be >> debated since basically all attacks requires some sort of conscious = act. >=20 > A MiTM attack by definition requires the ability to inject messages = into the network. As far as I know, that's the usual distinguishing = factor in "active" vs "passive" attacks. >=20 From ben@nostrum.com Fri Jun 1 14:18:23 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8256321F87EE for ; Fri, 1 Jun 2012 14:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.035 X-Spam-Level: X-Spam-Status: No, score=-102.035 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMoBAZPs3wli for ; Fri, 1 Jun 2012 14:18:23 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7D621F87F1 for ; Fri, 1 Jun 2012 14:18:22 -0700 (PDT) Received: from dn3-123.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q51LH3mf088645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Jun 2012 16:17:06 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Fri, 1 Jun 2012 16:17:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <92724ABE-44E0-419F-A4CF-1C4EFA1AD5AA@nostrum.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0CFA@ESESSCMS0356.eemea.ericsson.se> <7B321302-CDFC-4966-9928-CCB202E33AAC@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459128EE@ESESSCMS0356.eemea.ericsson.se> <8B33C1AA-3B30-413B-834C-2BFFF152E79D@nostrum.com> To: Eric Burger X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 21:18:23 -0000 On Jun 1, 2012, at 5:47 AM, Eric Burger wrote: > But, without CEMA you have no possibility of end-to-end encryption. = At least with CEMA you have the possibility. >=20 Do you mean that statement in general, or in the case of MSRP traversing = media-steering middleboxes? I agree with the later, but not the former. [...] From ben@nostrum.com Fri Jun 1 14:18:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6045921F87FB for ; Fri, 1 Jun 2012 14:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYFrnUb1OFpx for ; Fri, 1 Jun 2012 14:18:52 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D1CDE21F87FA for ; Fri, 1 Jun 2012 14:18:51 -0700 (PDT) Received: from dn3-123.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q51LH3mg088645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Jun 2012 16:17:47 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C459A38F4@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 1 Jun 2012 16:17:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0D0C@ESESSCMS0356.eemea.ericsson.se> <2CDCC2EF-B5AF-4101-857C-0B9E42F381A8@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459128EF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C459A338F@ESESSCMS0356.eemea.ericsson.se> <5F1730E7-0C2D-49F1-8C8E-B5B065BABF90@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459A38F4@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 21:18:52 -0000 On Jun 1, 2012, at 2:39 AM, Christer Holmberg wrote: > Hi, >=20 >>>> I don't think the definition needs to describe the entire process. = could we just say "name of the peer", perhaps with a disclaimer that = that the meaning of "name" is as described by the protocol? >>>=20 >>> So, something like: >>>=20 >>>=20 >>> "Name Based Authentication: An authentication method in which an=20= >>> endpoint receives an X.509 certificate from its peer as part of = the=20 >>> TLS authentication. The endpoint validates that a chain of = issuers exists=20 >>> from the certificate to a trusted certification authority, and = that the=20 >>> certificate contains the name (as indicated in SIP/SDP) of the=20= >>> peer." >>>=20 >>>=20 >>=20 >> Works for me. >=20 > Actually, we noted that the suggested text does not take RFC 6072 into = consideration. So, what about: >=20 > "Name Based Authentication: An authentication method in which an=20= > endpoint receives an X.509 certificate from its peer as part of = the=20 > TLS authentication. The endpoint verifies that the identity = associated=20 > with the certificate corresponds to that of the peer (as = indicated in SIP/SDP)=20 > and that the binding of the identity to the public key was done = by a party which the > endpoint trusts. This definition includes both traditional = certificates issued by a=20 > well-known certification authority as well as self-signed = certificates published via=20 > a SIP Certificate Management Service [RFC6072] and other similar = mechanisms." Either version works for me. Thanks! Ben.= From eburger@standardstrack.com Fri Jun 1 14:21:58 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962D621F889A for ; Fri, 1 Jun 2012 14:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4Cxhvo0E8PG for ; Fri, 1 Jun 2012 14:21:57 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 5088A21F88AB for ; Fri, 1 Jun 2012 14:21:54 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:63488 helo=[192.168.15.135]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SaZI7-0001RW-9J; Fri, 01 Jun 2012 14:21:51 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-224--498817543; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <92724ABE-44E0-419F-A4CF-1C4EFA1AD5AA@nostrum.com> Date: Fri, 1 Jun 2012 17:20:35 -0400 Message-Id: <03A6F766-2C9B-48E3-B703-B198193FFE4C@standardstrack.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0CFA@ESESSCMS0356.eemea.ericsson.se> <7B321302-CDFC-4966-9928-CCB202E33AAC@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C459128EE@ESESSCMS0356.eemea.ericsson.se> <8B33C1AA-3B30-413B-834C-2BFFF152E79D@nostrum.com> <92724ABE-44E0-419F-A4CF-1C4EFA1AD5AA@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 21:21:58 -0000 --Apple-Mail-224--498817543 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The latter. As you and others have pointed out, there's nothing we can = do with relays that by definition have to read the plaintext of the = message. On Jun 1, 2012, at 5:17 PM, Ben Campbell wrote: >=20 > On Jun 1, 2012, at 5:47 AM, Eric Burger wrote: >=20 >> But, without CEMA you have no possibility of end-to-end encryption. = At least with CEMA you have the possibility. >>=20 >=20 > Do you mean that statement in general, or in the case of MSRP = traversing media-steering middleboxes? I agree with the later, but not = the former. >=20 > [...] >=20 --Apple-Mail-224--498817543 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjAxMjEyMDM1WjAjBgkqhkiG9w0BCQQxFgQU VetOs0nLDAX/QgQ+eix9etxHjtcwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAAgAz6C7BNPv83Vnb2xno+jMsg5WfZRW1CQCPU3z1HXFPnow4E9w1 +8wHvj2VVCwz8GAdc7niNYvY4txTax7tzIDYxg3hhSsfvC9RsO7uKrjchPCcqIVicGrNTAcdCGzs TTZ9Id1nrqR19Wcq05aCZYmKbKmq8bIavZkmiNZHJ9zT8k+TAnjt1X/iQpwjUgWLkdxcprR5FZ/C O/V7HnT4bzlqb3nLfGW8MS9JvXraHVNplrfdevuUwfG2svAbIsGFqCyRDSaqkupwTpC1LguZEWnm ogzsznpdb+WlbeW79Loov+uLzmKraBTLxPP8L+Gx9ZRUbiY8dSHd8370Qn3+swAAAAAAAA== --Apple-Mail-224--498817543-- From saul@ag-projects.com Thu Jun 14 07:37:04 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC0D21F854D for ; Thu, 14 Jun 2012 07:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQwS01OmGk9f for ; Thu, 14 Jun 2012 07:37:03 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B6DE121F8525 for ; Thu, 14 Jun 2012 07:37:03 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id DB861B0079; Thu, 14 Jun 2012 16:37:01 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 43B02B006F; Thu, 14 Jun 2012 16:37:01 +0200 (CEST) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jun 2012 16:37:00 +0200 Message-Id: To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Simple] Using nicknames in conference event packages (draft-ietf-simple-chat) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 14:37:04 -0000 Hi, The draft-ietf-simple-chat specification states that the 'nickname' = extension defined by XCON (RFC 6501) should be used to convey the = nickname in the conference event package. I think section 7.4 could = clarify this a bit more, since the following may happen: Alice joins the conference from multiple endpoints, but same AoR. The = way the conference event payload is defined, there will be only one = element, because the 'entity' attribute needs to be unique and in = the context of a SIP conference the entity most likely will be the = user's AoR. There will be 2 elements, representing each of = Alice's SIP clients, so putting the nickname there would IMHO make more = sense. Also, using XCON just for the nickname attribute may not be desired by = some (that's me at least :-) ) so what about adding something along = these lines to section 7.4? "A conference focus MAY choose to use the = display-text element in the 'endpoint' or 'user' element to convey the = user's nickname". Regards, =20 -- Sa=FAl Ibarra Corretg=E9 AG Projects From internet-drafts@ietf.org Mon Jun 25 16:03:32 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E511E80C1; Mon, 25 Jun 2012 16:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiE33dzkg7uk; Mon, 25 Jun 2012 16:03:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44F811E808F; Mon, 25 Jun 2012 16:03:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120625230329.6072.42815.idtracker@ietfa.amsl.com> Date: Mon, 25 Jun 2012 16:03:29 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-msrp-cema-06.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:03:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presence Le= veraging Extensions Working Group of the IETF. Title : Connection Establishment for Media Anchoring (CEMA) for = the Message Session Relay Protocol (MSRP) Author(s) : Christer Holmberg Staffan Blau Eric Burger Filename : draft-ietf-simple-msrp-cema-06.txt Pages : 22 Date : 2012-06-25 Abstract: This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of the extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages, and thus also enables a secure end-to-end MSRP communication in networks where such middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-cema There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-simple-msrp-cema-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Mon Jun 25 16:07:22 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7EB11E80AE for ; Mon, 25 Jun 2012 16:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E8-cIiskeDk for ; Mon, 25 Jun 2012 16:07:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8A711E808F for ; Mon, 25 Jun 2012 16:07:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-02-4fe8ef274973 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7A.A5.28636.72FE8EF4; Tue, 26 Jun 2012 01:07:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 26 Jun 2012 01:07:19 +0200 From: Christer Holmberg To: "simple@ietf.org" Date: Tue, 26 Jun 2012 01:07:18 +0200 Thread-Topic: Draft new version: draft-ietf-simple-msrp-cema-06 Thread-Index: AQHNUydECnrb9V7D30mRkMNbMg5Bgg== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853405AF4115@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvra7G+xf+Bst+clgsnPiP1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGYcP3mEseM9YsfH8NNYGxv2MXYwcHBICJhLb3qh3MXICmWIS F+6tZ+ti5OIQEjjFKHF+0hJmkISQwEJGiaYfIiD1bAIWEt3/tEHCIgLqEg+PPmAFsVkEVCVO Pv8LVi4sYCXxf8MCNogae4njD/YygbSKCOhJrP6YDxLmFQiXeP5oBTuIzQi09vupNUwgNrOA uMStJ/OZIM4RkFiy5zwzhC0q8fLxP1aIelGJO+3rGSHq9SRuTJ3CBmFrSyxb+JoZYr6gxMmZ T1gmMArPQjJ2FpKWWUhaZiFpWcDIsopRODcxMye93FAvtSgzubg4P0+vOHUTIzCwD275rbuD 8dQ5kUOM0hwsSuK8XEn7/YUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwMl9y2S06dYLMH46/ 0+p/WFadrXtv1DEjZTbLJo0fYgxq5dOa5GfWncyZZ6/PuWPvUm3uqSsEmRM5VYI8pkvMu8G5 80tE/4KZXXMs+e7H33C6z3Jo/fc7ezQ87mul7sywTM/f6PTD8buD5p1tgVf9Dq05fzXyZJP5 H4Ujvr9VCixPL7x1fIrtOSWW4oxEQy3mouJEAIeGhGs6AgAA Subject: [Simple] Draft new version: draft-ietf-simple-msrp-cema-06 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:07:22 -0000 Hi, Based on Ben's comments, I've submitted a new version (-06) of the cema dra= ft, with some modifications in the security considerations section. The new= text should address Ben's issues and suggestions. Regards, Christer From ben@estacado.net Wed Jun 27 13:35:03 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C5421F868A for ; Wed, 27 Jun 2012 13:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+ovoi3JbRDG for ; Wed, 27 Jun 2012 13:35:03 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2D64621F8627 for ; Wed, 27 Jun 2012 13:35:03 -0700 (PDT) Received: from [10.12.30.47] ([10.12.30.47]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q5RKXfxA000874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 15:33:42 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853405AF4115@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 27 Jun 2012 15:33:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05853405AF4115@ESESSCMS0356.eemea.ericsson.se> To: Simple WG X-Mailer: Apple Mail (2.1278) Subject: Re: [Simple] Draft new version: draft-ietf-simple-msrp-cema-06 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:35:04 -0000 As Chair: Hi Everyone: Christer, thanks for submitting this. Everyone, please take a quick look at the security considerations in = this version, and send comments ASAP if you see an issue. If you made = comments in the WGLC, please confirm whether your comments are addressed = (I'm not sure if anyone but me did--maybe Paul?). If we don't see an = objection the end of the week, we plan to restart the process to = progress this. Additionally, we've had a Security AD suggestion to add text (probably = to section 7.7) to the effect of the following, which would add SHOULD = level normative requirements to watch for changes in a fingerprint for = an identity, and warn of any changes. If anyone objects to adding that, = please speak up ASAP. > "When a UA receives a fingerprint, that represents a binding > between the identity as established by TLS and that established > via SDP. As previously noted, the fingerprint is vulnerable to > an active MITM attack from any on-path proxy. UAs SHOULD > therefore locally store fingerprints associated with the > relevant identities when first seen, and SHOULD warn when a > new fingerprint is seen for what otherwise appears to be the > same peer identity. While there are valid reasons for keys > to change from time to time, that ought be the exception, > hence the suggested warning." Thanks! Ben. On Jun 25, 2012, at 6:07 PM, Christer Holmberg wrote: > Hi, >=20 > Based on Ben's comments, I've submitted a new version (-06) of the = cema draft, with some modifications in the security considerations = section. The new text should address Ben's issues and suggestions. >=20 > Regards, >=20 > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Wed Jun 27 13:40:22 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D300E21F85E5 for ; Wed, 27 Jun 2012 13:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUCfqc0GViVz for ; Wed, 27 Jun 2012 13:40:22 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id F2C7B21F85D3 for ; Wed, 27 Jun 2012 13:40:21 -0700 (PDT) Received: from [10.12.30.47] ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q5RKeDpM003096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 15:40:16 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Wed, 27 Jun 2012 15:40:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05853405AF4115@ESESSCMS0356.eemea.ericsson.se> To: Simple WG X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: Re: [Simple] Draft new version: draft-ietf-simple-msrp-cema-06 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:40:22 -0000 As individual: This revision, along with discussion, addresses my comments to my = satisfaction. I have no objection to the proposed new normative change. When I first = thought about this addition, I wondered why we would burden CEMA with = it, rather than find a way to apply it to MSRP in general. But on = reflection, it seems like CEMA is really about making MSRP easier to use = over middleboxes. I think this makes it reasonable to hold CEMA to a = higher standard for fingerprint management. If we do some general update = to MSRP in the future, we might still consider adding the requirement to = the general case. We should consider, however, whether CEMA has any common use cases = where a self-signed certificate and associated fingerprint would change = all the time. (e.g. if self-signed certs were ephemeral). Thanks! Ben. On Jun 27, 2012, at 3:33 PM, Ben Campbell wrote: > As Chair: >=20 > Hi Everyone: >=20 > Christer, thanks for submitting this. >=20 > Everyone, please take a quick look at the security considerations in = this version, and send comments ASAP if you see an issue. If you made = comments in the WGLC, please confirm whether your comments are addressed = (I'm not sure if anyone but me did--maybe Paul?). If we don't see an = objection the end of the week, we plan to restart the process to = progress this. >=20 > Additionally, we've had a Security AD suggestion to add text (probably = to section 7.7) to the effect of the following, which would add SHOULD = level normative requirements to watch for changes in a fingerprint for = an identity, and warn of any changes. If anyone objects to adding that, = please speak up ASAP. >=20 >> "When a UA receives a fingerprint, that represents a binding >> between the identity as established by TLS and that established >> via SDP. As previously noted, the fingerprint is vulnerable to >> an active MITM attack from any on-path proxy. UAs SHOULD >> therefore locally store fingerprints associated with the >> relevant identities when first seen, and SHOULD warn when a >> new fingerprint is seen for what otherwise appears to be the >> same peer identity. While there are valid reasons for keys >> to change from time to time, that ought be the exception, >> hence the suggested warning." >=20 >=20 >=20 > Thanks! >=20 > Ben. >=20 >=20 >=20 >=20 > On Jun 25, 2012, at 6:07 PM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> Based on Ben's comments, I've submitted a new version (-06) of the = cema draft, with some modifications in the security considerations = section. The new text should address Ben's issues and suggestions. >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 From ben@estacado.net Fri Jun 29 12:47:33 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D5921F888E for ; Fri, 29 Jun 2012 12:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ukz6596kQquu for ; Fri, 29 Jun 2012 12:47:32 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id E8AEF21F86B0 for ; Fri, 29 Jun 2012 12:47:31 -0700 (PDT) Received: from [10.12.30.47] ([10.12.30.47]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q5TJkE6H098143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 29 Jun 2012 14:46:15 -0500 (CDT) (envelope-from ben@estacado.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Ben Campbell In-Reply-To: Date: Fri, 29 Jun 2012 14:46:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05853405AF4115@ESESSCMS0356.eemea.ericsson.se> To: Simple WG X-Mailer: Apple Mail (2.1278) Subject: Re: [Simple] Draft new version: draft-ietf-simple-msrp-cema-06 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:47:33 -0000 (As Chair, adding to the previous...) Christer also proposed the following change to section 7.7 to go along = with the previous proposed addition: >> Section 7.7 currently says: >>=20 >> "There is no way for the endpoints to discover when such an = attack is >> taking place though." >>=20 >> I guess we should change that to something like: >>=20 >> "It is very hard for the endpoints to detect when such an attack = is >> taking place though." >=20 If anyone objects to that change, please speak up ASAP. Thanks! Ben. On Jun 27, 2012, at 3:33 PM, Ben Campbell wrote: > As Chair: >=20 > Hi Everyone: >=20 > Christer, thanks for submitting this. >=20 > Everyone, please take a quick look at the security considerations in = this version, and send comments ASAP if you see an issue. If you made = comments in the WGLC, please confirm whether your comments are addressed = (I'm not sure if anyone but me did--maybe Paul?). If we don't see an = objection the end of the week, we plan to restart the process to = progress this. >=20 > Additionally, we've had a Security AD suggestion to add text (probably = to section 7.7) to the effect of the following, which would add SHOULD = level normative requirements to watch for changes in a fingerprint for = an identity, and warn of any changes. If anyone objects to adding that, = please speak up ASAP. >=20 >> "When a UA receives a fingerprint, that represents a binding >> between the identity as established by TLS and that established >> via SDP. As previously noted, the fingerprint is vulnerable to >> an active MITM attack from any on-path proxy. UAs SHOULD >> therefore locally store fingerprints associated with the >> relevant identities when first seen, and SHOULD warn when a >> new fingerprint is seen for what otherwise appears to be the >> same peer identity. While there are valid reasons for keys >> to change from time to time, that ought be the exception, >> hence the suggested warning." >=20 >=20 >=20 > Thanks! >=20 > Ben. >=20 >=20 >=20 >=20 > On Jun 25, 2012, at 6:07 PM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> Based on Ben's comments, I've submitted a new version (-06) of the = cema draft, with some modifications in the security considerations = section. The new text should address Ben's issues and suggestions. >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From md3135@att.com Fri Jun 29 15:11:08 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D588621F86B3 for ; Fri, 29 Jun 2012 15:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS09X6AROy8w for ; Fri, 29 Jun 2012 15:11:06 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id AD6B421F86A4 for ; Fri, 29 Jun 2012 15:11:04 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id af72eef4.2aaad1214940.44707.00-587.126407.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 29 Jun 2012 22:11:06 +0000 (UTC) X-MXL-Hash: 4fee27fa2681ce4a-710bfa1b8544f993a421df9c62d837212c588a9f Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 8c72eef4.0.44549.00-480.125936.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 29 Jun 2012 22:10:56 +0000 (UTC) X-MXL-Hash: 4fee27f064393f7d-eac34cf0f60796a5b075581a95c72b7dae321c17 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5TMAFSA032411; Fri, 29 Jun 2012 15:10:15 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5TMA8Hx032360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 15:10:10 -0700 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 29 Jun 2012 15:09:49 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 18:09:48 -0400 From: "DOLLY, MARTIN C" To: Ben Campbell Thread-Topic: [Simple] Draft new version: draft-ietf-simple-msrp-cema-06 Thread-Index: AQHNVi/TATnHcrqjSzSfeWb3XdfzrJcR22zf Date: Fri, 29 Jun 2012 22:09:48 +0000 Message-ID: <5BBCD7EF-64C4-4FEC-BEED-33831A43B6D0@att.com> References: <7F2072F1E0DE894DA4B517B93C6A05853405AF4115@ESESSCMS0356.eemea.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=QgueEjTIxVcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=y2] X-AnalysisOut: [iVHjvUAAAA:8 a=48vgC7mUAAAA:8 a=LDrtRfaUa9ujD1sKyigA:9 a=C] X-AnalysisOut: [juIK1q_8ugA:10 a=qM39cor4HRgA:10 a=rYRWyWsPAzQA:10 a=lZB81] X-AnalysisOut: [5dzVvQA:10] Cc: Simple WG Subject: Re: [Simple] Draft new version: draft-ietf-simple-msrp-cema-06 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 22:11:08 -0000 Change looks good..... Anyone... Martin C. Dolly Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink Possible. +1.609.903.3360 ----------- Sent from my iPhone On Jun 29, 2012, at 3:47 PM, "Ben Campbell" wrote: > (As Chair, adding to the previous...) >=20 > Christer also proposed the following change to section 7.7 to go along wi= th the previous proposed addition: >=20 >>> Section 7.7 currently says: >>>=20 >>> "There is no way for the endpoints to discover when such an attack i= s >>> taking place though." >>>=20 >>> I guess we should change that to something like: >>>=20 >>> "It is very hard for the endpoints to detect when such an attack is >>> taking place though." >>=20 >=20 >=20 > If anyone objects to that change, please speak up ASAP. >=20 >=20 > Thanks! >=20 > Ben. >=20 >=20 > On Jun 27, 2012, at 3:33 PM, Ben Campbell wrote: >=20 >> As Chair: >>=20 >> Hi Everyone: >>=20 >> Christer, thanks for submitting this. >>=20 >> Everyone, please take a quick look at the security considerations in th= is version, and send comments ASAP if you see an issue. If you made comment= s in the WGLC, please confirm whether your comments are addressed (I'm not = sure if anyone but me did--maybe Paul?). If we don't see an objection the e= nd of the week, we plan to restart the process to progress this. >>=20 >> Additionally, we've had a Security AD suggestion to add text (probably t= o section 7.7) to the effect of the following, which would add SHOULD leve= l normative requirements to watch for changes in a fingerprint for an ident= ity, and warn of any changes. If anyone objects to adding that, please spea= k up ASAP. >>=20 >>> "When a UA receives a fingerprint, that represents a binding >>> between the identity as established by TLS and that established >>> via SDP. As previously noted, the fingerprint is vulnerable to >>> an active MITM attack from any on-path proxy. UAs SHOULD >>> therefore locally store fingerprints associated with the >>> relevant identities when first seen, and SHOULD warn when a >>> new fingerprint is seen for what otherwise appears to be the >>> same peer identity. While there are valid reasons for keys >>> to change from time to time, that ought be the exception, >>> hence the suggested warning." >>=20 >>=20 >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>=20 >>=20 >>=20 >> On Jun 25, 2012, at 6:07 PM, Christer Holmberg wrote: >>=20 >>> Hi, >>>=20 >>> Based on Ben's comments, I've submitted a new version (-06) of the cema= draft, with some modifications in the security considerations section. The= new text should address Ben's issues and suggestions. >>>=20 >>> Regards, >>>=20 >>> Christer >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From nancy.greene@ericsson.com Fri Jun 29 15:20:09 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4D11E8072 for ; Fri, 29 Jun 2012 15:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9l7WgnCflUA for ; Fri, 29 Jun 2012 15:20:08 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 623F621F84DF for ; Fri, 29 Jun 2012 15:20:08 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5TMDLW7013561; Fri, 29 Jun 2012 17:13:25 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.184]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 29 Jun 2012 18:13:22 -0400 From: Nancy Greene To: Ben Campbell Date: Fri, 29 Jun 2012 18:13:21 -0400 Thread-Topic: [Simple] Draft new version: draft-ietf-simple-msrp-cema-06 Thread-Index: AQHNVi/TATnHcrqjSzSfeWb3XdfzrJcR22zfgAAAnCA= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05853405AF4115@ESESSCMS0356.eemea.ericsson.se> , <5BBCD7EF-64C4-4FEC-BEED-33831A43B6D0@att.com> In-Reply-To: <5BBCD7EF-64C4-4FEC-BEED-33831A43B6D0@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simple WG Subject: Re: [Simple] Draft new version: draft-ietf-simple-msrp-cema-06 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 22:20:09 -0000 The new text looks fine. Nancy www.ericsson.com - This Communication is Confidential. We only send and re= ceive email on the basis of the term set out at www.ericsson.com/email_disc= laimer =20 On Jun 29, 2012, at 3:47 PM, "Ben Campbell" wrote: > (As Chair, adding to the previous...) >=20 > Christer also proposed the following change to section 7.7 to go along wi= th the previous proposed addition: >=20 >>> Section 7.7 currently says: >>>=20 >>> "There is no way for the endpoints to discover when such an attack i= s >>> taking place though." >>>=20 >>> I guess we should change that to something like: >>>=20 >>> "It is very hard for the endpoints to detect when such an attack is >>> taking place though." >>=20 >=20 >=20 > If anyone objects to that change, please speak up ASAP. >=20 >=20 > Thanks! >=20 > Ben. >=20 >=20 > On Jun 27, 2012, at 3:33 PM, Ben Campbell wrote: >=20 >> As Chair: >>=20 >> Hi Everyone: >>=20 >> Christer, thanks for submitting this. >>=20 >> Everyone, please take a quick look at the security considerations in th= is version, and send comments ASAP if you see an issue. If you made comment= s in the WGLC, please confirm whether your comments are addressed (I'm not = sure if anyone but me did--maybe Paul?). If we don't see an objection the e= nd of the week, we plan to restart the process to progress this. >>=20 >> Additionally, we've had a Security AD suggestion to add text (probably t= o section 7.7) to the effect of the following, which would add SHOULD leve= l normative requirements to watch for changes in a fingerprint for an ident= ity, and warn of any changes. If anyone objects to adding that, please spea= k up ASAP. >>=20 >>> "When a UA receives a fingerprint, that represents a binding between=20 >>> the identity as established by TLS and that established via SDP. As=20 >>> previously noted, the fingerprint is vulnerable to an active MITM=20 >>> attack from any on-path proxy. UAs SHOULD therefore locally store=20 >>> fingerprints associated with the relevant identities when first=20 >>> seen, and SHOULD warn when a new fingerprint is seen for what=20 >>> otherwise appears to be the same peer identity. While there are=20 >>> valid reasons for keys to change from time to time, that ought be=20 >>> the exception, hence the suggested warning." >>=20 >>=20 >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>=20 >>=20 >>=20 >> On Jun 25, 2012, at 6:07 PM, Christer Holmberg wrote: >>=20 >>> Hi, >>>=20 >>> Based on Ben's comments, I've submitted a new version (-06) of the cema= draft, with some modifications in the security considerations section. The= new text should address Ben's issues and suggestions. >>>=20 >>> Regards, >>>=20 >>> Christer >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple