From nobody Wed Jan 2 14:49:25 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B4B130FB4; Wed, 2 Jan 2019 14:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BR9A5intuNg; Wed, 2 Jan 2019 14:49:15 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD15130F46; Wed, 2 Jan 2019 14:49:09 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x02Mn7Ta039649 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Jan 2019 16:49:08 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1546469349; bh=UZEYZrpYPdhpF4jSdEpe+1f0kQM2wSdye6ng4C4h3+c=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=lpTq/2OrvtUvSiEu6fXODkByvo1VJaklcwUha83Hgze2ey03YntG3/boEzHPoYfGM kUluitsblM6fAw4frOJP+mV7OJnZ/YjD0fEbJORhC4x6xDyOxki+nyHsHleTcx1q5D BtO1xjD0CZWJA8gzxTiWSlb79AGpCzFLnXLp7LKk= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <3018856E-1EE2-4C96-9A1E-EB8EEAC0F2C8@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_960DA0A1-B955-442F-BBEA-6628B04E5BD1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 2 Jan 2019 16:49:06 -0600 In-Reply-To: Cc: draft-ietf-sipbrandy-rtpsec.all@ietf.org, sipbrandy@ietf.org To: Russ Housley References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-rtpsec-06 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 22:49:24 -0000 --Apple-Mail=_960DA0A1-B955-442F-BBEA-6628B04E5BD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the response. Some additional comments inline: > On Dec 30, 2018, at 4:56 PM, Russ Housley = wrote: >=20 > Ben: >=20 > Thanks for the thoughtful and careful review. >=20 > Responding only to your Substantive Comments for now... >=20 >> =C2=A74: >> - general: The section explains the requirement that the AS and VS to = be colocated with the caller and recipient UAs as because putting them = in an intermediary could allow that intermediary to act as a MitM. = Isn=E2=80=99t this more a question of trust than physical location? = Users already need to trust the AS and VS for STIR to work at all. In = particular, I don=E2=80=99t think it=E2=80=99s safe to imply that a = local AS _can=E2=80=99t_ act as a MiTM unless the code is inspected (and = perhaps signed) by a trusted entity. >>=20 >> For the record, I do not necessarily object to the colocation = requirement; I=E2=80=99m just not entirely buying the explanation for = it. >=20 > The SIPBRANDY profile is based on an end-to-end trust model. The = verification could take place at an intermediary, but to get the = end-to-end assurance, the verification would need to be repeated at the = end. Does the draft actually say that somewhere I missed? I see text saying = that an intermediary could do verification, but must not block or = redirect calls due to an untrusted signing credentials. I don=E2=80=99t = see anything that states the verification needs to happen again at the = endpoint. But in general, I think the section would benefit from more focus of = what an e2e trust model really means. There=E2=80=99s mention of it in = the second paragraph, but not really a definition. I also wonder how = such a definition would apply to a decomposed endpoint. (e.g. a media = server that separates SIP processing and (S)RTP processing) >=20 >> - 2nd paragraph: "While intermediaries MAY provide the verification = service function of STIR for SIPBRANDY transactions,=E2=80=9D: That = seems to contradict the statement in the following paragraph that the = user agent implementations MUST implement both the AS and VS. >=20 > Again, verification could take place at an intermediary for their own = purposes, but the end-to-end assurance is only provided if the check is = made at the end as well. See previous comments; does the draft actually say that somewhere? >=20 >> =C2=A74.1: >> - General: This section talks about self-signed certs and TOFU. Would = you characterize those as comprehensive security? I suspect not, since = they offer more exposure to active attacks. But I=E2=80=99m not sure = they qualify as =E2=80=9Copportunistic=E2=80=9D, since they don=E2=80=99t = (necessarily) allow a fallback to cleartext. In any case, some text = discussing this question might be helpful. (This also includes =C2=A74.2) >=20 > No, I would not characterize the use of self-signed certificates as = comprehensive security. This section is suggesting them as an = alternative when other certificates are not available for the caller = identity. The PKI for telephone numbers is not yet available, but it is = coming. The PKI for a SIP URI without a telephone number (e.g. = "sip:alice@example.com") is not being worked yet. Sp, self-signed = certificates give a way to start. An active attacker could strip the = signature altogether. Does that mean you would lump it into =E2=80=9Copportunistic=E2=80=9D? = Or do we have a third, in-between category? >=20 >> - third paragraph: "This profile of STIR therefore relaxes the = authority requirements of [RFC8224]=E2=80=9D >> Does that require this draft to formally update 8224? >=20 > I do not think so. RFC 8224 says: >=20 > ... Similar practices could be used to support opportunistic > signing of SIP requests for UA-integrated authentication services > with self-signed certificates, though that is outside the scope of > this specification and is left as a matter for future investigation. > Note, however, that even when using anonymous SIP URIs, an > authentication service must possess a certificate corresponding to > the host portion of the addr-spec of the =46rom header field value = of > the request; accordingly, using domains like "anonymous.invalid" > will not be usable by privacy services that simultaneously act as > authentication services. The assurance offered by the usage of > anonymous URIs with a valid domain portion is "this is a known user > in my domain that I have authenticated, but I am keeping its = identity > private.=E2=80=9D I was wondering if there were some other normative requirement in 8224 = that was being relaxed. On a quick scan, I do not find any. Therefore = perhaps this should be an =E2=80=9Ceditorial=E2=80=9D the language "This profile of STIR therefore relaxes the authority = requirements of [RFC8224] to allow the use of self-signed keys for authentication services that are composed = with user agent=E2=80=9D ... suggests that this draft relaxes some specific requirement for this = specific composition; that doesn=E2=80=99t seem to be true. >=20 >> =C2=A74.3: Does this draft need to formally update 4916? It=E2=80=99s = not clear to me if this draft intends to update these, or is stating = that these are some updates we should do in the future. The last = paragraph suggests the latter, but the rest of the section seems to be = more the former. >=20 > Yes, it probably should update RFC 4916. If that is the case, I think the section needs to split the list of = updates to clarify which are actually made by this draft, vs reserved = for future work. (For example, I assume this draft is not going to = update the examples to match 8224) >=20 >> =C2=A74.4, last paragraph: Is there an expectation that the UA will = alert the user if it allows the dialog to continue without media = security? >=20 > Since the IETF does not normally get into user interface, the "if = policy permits" language would allow the user to be involved in the = decision, or it could be set by other means. Okay. I=E2=80=99m not going to insist, but I think one could offer (perhaps = non-normative) guidance that there are security implications if a user = thinks a session is secure when it is not. Thanks! Ben. --Apple-Mail=_960DA0A1-B955-442F-BBEA-6628B04E5BD1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwtP+IACgkQgFZKbJXz 1A0wuA//R8cff4pG1EPYI9ES5vFNvkpBm8g6Y0W3vb47QKml0Ue48V9v1ebSA4zt IaJVNnt4sSfVaBLLTXNYTGCKchAvH6uB1a148sw7aigBb4+7upIi5YdTU2Zk9/BZ N8LHD21oF542vZmOv0CO9YiWyVD5uDVFg8IGPEvQ9raTrPL2RQfFUz5yjsLAmvWm Hi+o38QrfbIuO3QPLr+bwwuWw/O5fP1YKEUvO/v1jG1H1Rkh5jKXl2L90EkAMyig +Vpd6m86Hxpq+sEKu2Z23j5ft44LgEQIg3VP3y343pMQ2aCm+n1QRVOKPDQ4uQBb kgvIX+USZoQqqgimxDHKGmMMia0/sXFh5kIrLvZsoFR0kGVWMDDbUZ7/+eavYktM 0hi3Dxute2+ooGMiv7PycrRcmeQQ2K9X1Y2R2SxzqyOqhzG2IIPO0pk/PXXZhsLa ghzB/ujQfiiNz5JffATOFxcq/1vrBoThQsiHxBkBPJauh5zCbMaSDt5FeYMTI+M6 uNXSbjOJdIsSkNR5FD2/WCgP6L6+20LAPZ7Ch0aQuOK5EmxFjyOLklIpzc+cvRXs HY7Y/bRfPG6O6P6s8z5dQLijPRfhypEnRNlO07cLx6a2VgmJgPdTxjq8EDs9mLTO 4XZAlg+pvqEkQgLh+zzfHxyTtClgX0bCC8KSvwIdjI+sCBf7pyM= =fQ/b -----END PGP SIGNATURE----- --Apple-Mail=_960DA0A1-B955-442F-BBEA-6628B04E5BD1-- From nobody Mon Jan 14 15:40:58 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98C313141E; Mon, 14 Jan 2019 15:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUt__hlbsSM0; Mon, 14 Jan 2019 15:40:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D3313143A; Mon, 14 Jan 2019 15:40:53 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0ENep07061554 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Jan 2019 17:40:52 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547509253; bh=SLQrW+A1h/kFxLmxwb+eVbTcjnK95af8oiwi9zRdqKo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=BzOwdKe+o5xTEePmEMomX1uoNfE3NYPa6w6GrUu6MIZnSyEMMpYWfLKRI6dLAmRXt KtltfWI9vKZfCtnmgYW1mRyAdpujlFgNx5hKWXcf8L1iBIysjCv0fVqQZ/n4ggzf8+ SwNZekzTtQkJBsN8cameeY1bnH7N8IdDnwT4BXh8= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <7669F9E0-EFBF-4E98-ADA5-6E5026A3AAAC@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0630F3A6-1E53-4A78-877E-499DD544217B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 14 Jan 2019 17:40:51 -0600 In-Reply-To: <3018856E-1EE2-4C96-9A1E-EB8EEAC0F2C8@nostrum.com> Cc: sipbrandy@ietf.org To: Russ Housley , draft-ietf-sipbrandy-rtpsec.all@ietf.org References: <3018856E-1EE2-4C96-9A1E-EB8EEAC0F2C8@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-rtpsec-06 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 23:40:56 -0000 --Apple-Mail=_0630F3A6-1E53-4A78-877E-499DD544217B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, any further thoughts? Thanks! Ben. > On Jan 2, 2019, at 4:49 PM, Ben Campbell wrote: >=20 > Thanks for the response. Some additional comments inline: >=20 >> On Dec 30, 2018, at 4:56 PM, Russ Housley = wrote: >>=20 >> Ben: >>=20 >> Thanks for the thoughtful and careful review. >>=20 >> Responding only to your Substantive Comments for now... >>=20 >>> =C2=A74: >>> - general: The section explains the requirement that the AS and VS = to be colocated with the caller and recipient UAs as because putting = them in an intermediary could allow that intermediary to act as a MitM. = Isn=E2=80=99t this more a question of trust than physical location? = Users already need to trust the AS and VS for STIR to work at all. In = particular, I don=E2=80=99t think it=E2=80=99s safe to imply that a = local AS _can=E2=80=99t_ act as a MiTM unless the code is inspected (and = perhaps signed) by a trusted entity. >>>=20 >>> For the record, I do not necessarily object to the colocation = requirement; I=E2=80=99m just not entirely buying the explanation for = it. >>=20 >> The SIPBRANDY profile is based on an end-to-end trust model. The = verification could take place at an intermediary, but to get the = end-to-end assurance, the verification would need to be repeated at the = end. >=20 > Does the draft actually say that somewhere I missed? I see text saying = that an intermediary could do verification, but must not block or = redirect calls due to an untrusted signing credentials. I don=E2=80=99t = see anything that states the verification needs to happen again at the = endpoint. >=20 > But in general, I think the section would benefit from more focus of = what an e2e trust model really means. There=E2=80=99s mention of it in = the second paragraph, but not really a definition. I also wonder how = such a definition would apply to a decomposed endpoint. (e.g. a media = server that separates SIP processing and (S)RTP processing) >=20 >>=20 >>> - 2nd paragraph: "While intermediaries MAY provide the verification = service function of STIR for SIPBRANDY transactions,=E2=80=9D: That = seems to contradict the statement in the following paragraph that the = user agent implementations MUST implement both the AS and VS. >>=20 >> Again, verification could take place at an intermediary for their own = purposes, but the end-to-end assurance is only provided if the check is = made at the end as well. >=20 > See previous comments; does the draft actually say that somewhere? >=20 >>=20 >>> =C2=A74.1: >>> - General: This section talks about self-signed certs and TOFU. = Would you characterize those as comprehensive security? I suspect not, = since they offer more exposure to active attacks. But I=E2=80=99m not = sure they qualify as =E2=80=9Copportunistic=E2=80=9D, since they don=E2=80= =99t (necessarily) allow a fallback to cleartext. In any case, some text = discussing this question might be helpful. (This also includes =C2=A74.2) >>=20 >> No, I would not characterize the use of self-signed certificates as = comprehensive security. This section is suggesting them as an = alternative when other certificates are not available for the caller = identity. The PKI for telephone numbers is not yet available, but it is = coming. The PKI for a SIP URI without a telephone number (e.g. = "sip:alice@example.com") is not being worked yet. Sp, self-signed = certificates give a way to start. An active attacker could strip the = signature altogether. >=20 > Does that mean you would lump it into =E2=80=9Copportunistic=E2=80=9D? = Or do we have a third, in-between category? >=20 >>=20 >>> - third paragraph: "This profile of STIR therefore relaxes the = authority requirements of [RFC8224]=E2=80=9D >>> Does that require this draft to formally update 8224? >>=20 >> I do not think so. RFC 8224 says: >>=20 >> ... Similar practices could be used to support opportunistic >> signing of SIP requests for UA-integrated authentication services >> with self-signed certificates, though that is outside the scope of >> this specification and is left as a matter for future investigation. >> Note, however, that even when using anonymous SIP URIs, an >> authentication service must possess a certificate corresponding to >> the host portion of the addr-spec of the =46rom header field value = of >> the request; accordingly, using domains like "anonymous.invalid" >> will not be usable by privacy services that simultaneously act as >> authentication services. The assurance offered by the usage of >> anonymous URIs with a valid domain portion is "this is a known user >> in my domain that I have authenticated, but I am keeping its = identity >> private.=E2=80=9D >=20 > I was wondering if there were some other normative requirement in 8224 = that was being relaxed. On a quick scan, I do not find any. Therefore = perhaps this should be an =E2=80=9Ceditorial=E2=80=9D the language >=20 > "This profile of STIR therefore relaxes the authority = requirements of [RFC8224] to allow the use of > self-signed keys for authentication services that are composed = with > user agent=E2=80=9D >=20 > ... suggests that this draft relaxes some specific requirement for = this specific composition; that doesn=E2=80=99t seem to be true. >=20 >=20 >>=20 >>> =C2=A74.3: Does this draft need to formally update 4916? It=E2=80=99s = not clear to me if this draft intends to update these, or is stating = that these are some updates we should do in the future. The last = paragraph suggests the latter, but the rest of the section seems to be = more the former. >>=20 >> Yes, it probably should update RFC 4916. >=20 > If that is the case, I think the section needs to split the list of = updates to clarify which are actually made by this draft, vs reserved = for future work. (For example, I assume this draft is not going to = update the examples to match 8224) >=20 >>=20 >>> =C2=A74.4, last paragraph: Is there an expectation that the UA will = alert the user if it allows the dialog to continue without media = security? >>=20 >> Since the IETF does not normally get into user interface, the "if = policy permits" language would allow the user to be involved in the = decision, or it could be set by other means. >=20 > Okay. >=20 > I=E2=80=99m not going to insist, but I think one could offer (perhaps = non-normative) guidance that there are security implications if a user = thinks a session is secure when it is not. >=20 > Thanks! >=20 > Ben. >=20 --Apple-Mail=_0630F3A6-1E53-4A78-877E-499DD544217B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw9HgMACgkQgFZKbJXz 1A3cShAAyOqMsLPkOluzeKKCqu5p2WExqmvGQRzPnGDvlyg5r3vnZPx6hIYmT23e GyX5PeGi0eYsDf6jkP8UVtknNwtqqM2MZt4Cfa7LIsxfqrw6YboogsLynZ0HoeFn UhG14L272frxnnpUI3WR/PU+mWfmuvX35EEfnGZtDLr+vp2wJEVibqoQMnnOdExv ZOZcayqYZ/U2R39hjhNDEI3oduiKCLmXxF48btukSeNIBuKNsnpa0FKUEayxJlug I4Wpd8EdWEmwC5G6LH9vTBihV+GCquwm3Tj+fGycP/PP9+qCrKGn2Zqs+DJHj9ci n2z0iWs8g/EbU8RkHotJTGN+00RgYb5M9I/B7rgTy1EjalJ8aDY1Smg1cGivf0rn B1onmE9aN5gN4AhBToRnes0QAVNl3mtQn3ckqyfMpyMxC6c4lkOzkChsOxLbVa1d G5/rYh3/5RGR9Tf96sxE9BwLyGz+v8yQEciCl4aO4aCrlCf8RbXCsVp5ybd3seng rjHVebmSJPewFp48dwEM6tSk7B2Mna67lmOPSYO99z0aCYeSR68N11X3X+uUTZeM dRZ2eZQN2FN6IebwObNeiuyZ8yYDVrzubpqMdwJ4Iu93TzzWGVB8KOGVP9Ve7/WN uxJ34brn+arY+ZdkfF9bLn3E5eN/FnQ6mRm8g3VnMlyNb+JjThI= =mx0X -----END PGP SIGNATURE----- --Apple-Mail=_0630F3A6-1E53-4A78-877E-499DD544217B-- From nobody Tue Jan 15 07:00:47 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42607129C6A for ; Tue, 15 Jan 2019 07:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kE-SSRyDXuD for ; Tue, 15 Jan 2019 07:00:42 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F277129A87 for ; Tue, 15 Jan 2019 07:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1547564440; x=1550156440; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KtPQvfka0EHy5Ovr5/CrxSxtPW5jGi6pOgnE5Tk4VcQ=; b=EUIhksbagIW4bJ0qvthRitYTNKXOa+RtstZk130a69Fwj/fG2LDmdsZF87UFxLqc 25po1quh1dfcYy02Q+/bwctollFuMHevQ/1lSAv9cTZp+Wav3Qsz94XrIVUaXQSy NdPo7HMteXyFEEtqyrga+hg1VcOiSjWxK0O/+Kijb98=; X-AuditID: c1b4fb3a-5c9c29e00000672c-67-5c3df5984baa Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A7.50.26412.895FD3C5; Tue, 15 Jan 2019 16:00:40 +0100 (CET) Received: from ESESSMR504.ericsson.se (153.88.183.126) by ESESBMB501.ericsson.se (153.88.183.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 15 Jan 2019 16:00:37 +0100 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR504.ericsson.se (153.88.183.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 15 Jan 2019 16:00:35 +0100 Received: from [100.94.2.59] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.190) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 15 Jan 2019 16:00:34 +0100 To: Ben Campbell , Russ Housley , CC: References: <3018856E-1EE2-4C96-9A1E-EB8EEAC0F2C8@nostrum.com> <7669F9E0-EFBF-4E98-ADA5-6E5026A3AAAC@nostrum.com> From: Gonzalo Camarillo Openpgp: preference=signencrypt Autocrypt: addr=Gonzalo.Camarillo@ericsson.com; prefer-encrypt=mutual; keydata= xsBNBEtSyYUBCADL7itybUN0VVtGQuO81AdviJNSo/BIc6xuVUofHlr/U9CbQcSrRSggvTfa 6n5o9t9zAuwp9pp+hQfSzn4/LrEaV2BmEfAFclSl57IhsXDJecw58JqGZrjahIjgU+rmZKPE RqLzubmI3ltEolLb4kkB9Y8FIQBnE1N3O0wHp7BE8VI5pQX24UkRkEtUptmhwnaehURg9atb 1myxbt1nUDEA5PLJNbPeXxPRJ058OEnPtToRinSCJ7BFtD6PoeUWgOL4kKdRbMyswDikiXnN Ntj1VkDQ6yi7pOb2qkviOzKOf/smqm4ovMxUrET7SzKw4icArL+xQUW3ayJyfSju1o5rABEB AAHNJkdvbnphbG8gQ2FtYXJpbGxvIDxnY2FtYXJpbEBnbWFpbC5jb20+wsCBBBMBAgArAhsj BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAIZAQUCWhwGngUJFGzXmQAKCRDRM1CYcD+HNkjG CACG39D/tNsA5xxSqRtN3JJCTfpj+BWqRckMEpBjBWlOOtb94QY8r9NHRIDwvA5qCVYRqQTI qVyReNw/CkOuaah2rbCdhsng6ZAMzFovXSEnbz+wse4QiKybHvjlJJA9qQiNlne57NVlNvLN LrpZJGmSJlJBBEQRq3Z9Crl2tWFkB6mmoXNnoRej6eVmhFoAo3td5loHo55nqYVZYtAHbXan ggmPI12gUigKf4PuvIISpdokSlkpam02Y61ygtqrlYvNnM+GpbayW2X3ZY5x6bwUwfkRSUCj +xslGaRfJUwr8kUxhVlcLR6qVcjNxWeZf9XKVH86OxEJVUVFsChlDAvHzsBNBEtSyYUBCADB qzP0B7lWge5Hn1648WPWrmUg8r3723XL/zUZe1zyEVsY9VyWhrBmuEy7Xm7wdLt0+BBXWJez 7/wWR9w/63qT+3+W0fe6SDXeZqF+HtYO5QPuu/VYtex0e3TI2w4s53ZM5KQCQF60kTDoK43e 5a6/G2GCKMPpkVKxpIeOiDITiRXq9GV7KHkQpPczqj9ImWp2M9sEIngZRaKILU//TaiWnRGR i6vN/sAvfEuu1fXTwpR6bBdD9wIZgyeSqEgxnioDdyFZYkTFl9G8TuLxNIdpVPzW2M9PKRQs i/kl/Kadsgnd8RtlP7cPoIqLMjmOfGwR8EVbKpmkM1+iKJ+g9F/bABEBAAHCwGUEGAECAA8C GwwFAlocBq4FCRRs16kACgkQ0TNQmHA/hzamwgf/Tnr7/WYnKNmEYvwr/GxhSelVYsBwejkz tCXa4gmVkErgPBEYsUtWAP+jVoYndG74v/3zBPHl4CehE9RnAJ+lpsWjwsn0qPI7sCik3Xqv c44g/RQF9RSI8DckQM0MqLJNazzq4tBi/ZbILWNx2N4LrEzhwoePug3MDn3rCv1Xpr/B60or p1zixtSRKyZo+L7UjttUdJkqxUbC35pBlZlDAL2Dop9He7XwUFofyW1Xvn9xxx0NasnlJX9G 288peTb41bQrs9SqaH1aVLXBTo7S9o+8oB9DLTIIwDQqfxqTWpGIfBhiTm9d7ai9WcFC8jSW zJtc/6luXoGjvUlBzQx0jQ== Message-ID: <13c16230-f6ec-cd49-6ecb-3d8f182e7997@ericsson.com> Date: Tue, 15 Jan 2019 17:00:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7669F9E0-EFBF-4E98-ADA5-6E5026A3AAAC@nostrum.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbG9SHfGV9sYg4+rFC3md55mt1jwpYPV 4tWLm+wWK9adYnJg8Viy5CeTx6ydT1g8Vt35whrAHMVlk5Kak1mWWqRvl8CVMbn/IFvBT6OK G3d72RsYF2t2MXJySAiYSEye/pKli5GLQ0jgCKPEhh272CGcb4wS1y//ZIJzlqyYClV2iFHi 3IqjbCD9wgIeEnOWf2YFsUUESiWeP77LDmIzC0hI7JzSBdVwj1Fix/RVYEVsAhYSW27dZwGx +QXkJboWXGUGsRkF7vFKTHia38XIwcErYC9xZq42SJhFQFXiybmJTCC2qECsRPub9WA2r4Cg xMmZT8DGcAKVz+g5wgrSyiygKbF+lz7ECeISt57MZ4Kw5SWat84G2yQkoC2xec0pxgmMorOQ TJqF0D0LSfcsJN0LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG0cEtv612MB587niI UYCDUYmHV+29bYwQa2JZcWUuMMw4mJVEeMucbGKEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/4R EowREkhPLEnNTk0tSC2CyTJxcEo1MC6smr3/we0ZPervMw4uC6s8vfysP2eOcMJnraiNIWnr Z9/ZsNp225eCrArfGV83MkZmKXu+aFz4ivnC6zX88+1nSdddZJv7/umbriUOfx5W5vetKp26 baexKreDlFVXhf3nygXKQroPL3LcsumYUcT7YcWLsN7dbZF2TzIC5ou77uo5o35/02clluKM REMt5qLiRADq1m+tnwIAAA== Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-rtpsec-06 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 15:00:46 -0000 Authors, please, try and address all the comments Ben sent in his original email (on December 29th). Thanks! Cheers, Gonzalo On 15-Jan-19 01:40, Ben Campbell wrote: > Hi, any further thoughts? > > Thanks! > > Ben. > >> On Jan 2, 2019, at 4:49 PM, Ben Campbell wrote: >> >> Thanks for the response. Some additional comments inline: >> >>> On Dec 30, 2018, at 4:56 PM, Russ Housley wrote: >>> >>> Ben: >>> >>> Thanks for the thoughtful and careful review. >>> >>> Responding only to your Substantive Comments for now... >>> >>>> §4: >>>> - general: The section explains the requirement that the AS and VS to be colocated with the caller and recipient UAs as because putting them in an intermediary could allow that intermediary to act as a MitM. Isn’t this more a question of trust than physical location? Users already need to trust the AS and VS for STIR to work at all. In particular, I don’t think it’s safe to imply that a local AS _can’t_ act as a MiTM unless the code is inspected (and perhaps signed) by a trusted entity. >>>> >>>> For the record, I do not necessarily object to the colocation requirement; I’m just not entirely buying the explanation for it. >>> >>> The SIPBRANDY profile is based on an end-to-end trust model. The verification could take place at an intermediary, but to get the end-to-end assurance, the verification would need to be repeated at the end. >> >> Does the draft actually say that somewhere I missed? I see text saying that an intermediary could do verification, but must not block or redirect calls due to an untrusted signing credentials. I don’t see anything that states the verification needs to happen again at the endpoint. >> >> But in general, I think the section would benefit from more focus of what an e2e trust model really means. There’s mention of it in the second paragraph, but not really a definition. I also wonder how such a definition would apply to a decomposed endpoint. (e.g. a media server that separates SIP processing and (S)RTP processing) >> >>> >>>> - 2nd paragraph: "While intermediaries MAY provide the verification service function of STIR for SIPBRANDY transactions,”: That seems to contradict the statement in the following paragraph that the user agent implementations MUST implement both the AS and VS. >>> >>> Again, verification could take place at an intermediary for their own purposes, but the end-to-end assurance is only provided if the check is made at the end as well. >> >> See previous comments; does the draft actually say that somewhere? >> >>> >>>> §4.1: >>>> - General: This section talks about self-signed certs and TOFU. Would you characterize those as comprehensive security? I suspect not, since they offer more exposure to active attacks. But I’m not sure they qualify as “opportunistic”, since they don’t (necessarily) allow a fallback to cleartext. In any case, some text discussing this question might be helpful. (This also includes §4.2) >>> >>> No, I would not characterize the use of self-signed certificates as comprehensive security. This section is suggesting them as an alternative when other certificates are not available for the caller identity. The PKI for telephone numbers is not yet available, but it is coming. The PKI for a SIP URI without a telephone number (e.g. "sip:alice@example.com") is not being worked yet. Sp, self-signed certificates give a way to start. An active attacker could strip the signature altogether. >> >> Does that mean you would lump it into “opportunistic”? Or do we have a third, in-between category? >> >>> >>>> - third paragraph: "This profile of STIR therefore relaxes the authority requirements of [RFC8224]” >>>> Does that require this draft to formally update 8224? >>> >>> I do not think so. RFC 8224 says: >>> >>> ... Similar practices could be used to support opportunistic >>> signing of SIP requests for UA-integrated authentication services >>> with self-signed certificates, though that is outside the scope of >>> this specification and is left as a matter for future investigation. >>> Note, however, that even when using anonymous SIP URIs, an >>> authentication service must possess a certificate corresponding to >>> the host portion of the addr-spec of the From header field value of >>> the request; accordingly, using domains like "anonymous.invalid" >>> will not be usable by privacy services that simultaneously act as >>> authentication services. The assurance offered by the usage of >>> anonymous URIs with a valid domain portion is "this is a known user >>> in my domain that I have authenticated, but I am keeping its identity >>> private.” >> >> I was wondering if there were some other normative requirement in 8224 that was being relaxed. On a quick scan, I do not find any. Therefore perhaps this should be an “editorial” the language >> >> "This profile of STIR therefore relaxes the authority requirements of [RFC8224] to allow the use of >> self-signed keys for authentication services that are composed with >> user agent” >> >> ... suggests that this draft relaxes some specific requirement for this specific composition; that doesn’t seem to be true. >> >> >>> >>>> §4.3: Does this draft need to formally update 4916? It’s not clear to me if this draft intends to update these, or is stating that these are some updates we should do in the future. The last paragraph suggests the latter, but the rest of the section seems to be more the former. >>> >>> Yes, it probably should update RFC 4916. >> >> If that is the case, I think the section needs to split the list of updates to clarify which are actually made by this draft, vs reserved for future work. (For example, I assume this draft is not going to update the examples to match 8224) >> >>> >>>> §4.4, last paragraph: Is there an expectation that the UA will alert the user if it allows the dialog to continue without media security? >>> >>> Since the IETF does not normally get into user interface, the "if policy permits" language would allow the user to be involved in the decision, or it could be set by other means. >> >> Okay. >> >> I’m not going to insist, but I think one could offer (perhaps non-normative) guidance that there are security implications if a user thinks a session is secure when it is not. >> >> Thanks! >> >> Ben. >> >