Subject: [stir] Way outside the "box" use case

From: Eric Burger <[email-masked]>
Date: Mon, 29 Feb 2016 12:38:05 -0500

For the people on the STIR list: there is a potential WG being discussed in BA, LURK, that is principally looking at the problem of a content provider somehow allowing a CDN to sign on their behalf so that HTTPS and browsers “do the right thing.” If this sounds /similar/ to the STIR problem of delegated enterprise identity attestation, it should. See:
https://trac.tools.ietf.org/bof/trac/
and scroll down to “Security” or search for “LURK”.
PLEASE, if you care about this issue, continue the discussion on the LURK list, not the STIR list. Thanks. See:
https://www.ietf.org/mailman/listinfo/lurk

For the people on the LURK list: I do not necessarily advocate for or assume the STIR problem is in scope. However, if you and they have a compelling case for why it should be in scope, or if it is kind of in scope but appropriate for a later rechartering once we finish the HTTPS (and possibly DTLS) use case, say so, too. If you are curious about what STIR is, see:
https://trac.tools.ietf.org/wg/stir/charters

Thanks,
Eric

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 29 Feb 2016 18:46:53 +0000

I do agree there's a general problem here, actually, and I've given some
thought to the relationship between credential delegation in STIR and
existing systems like Keyless SSL for CDNs. In SIP networks that have a
"roaming" architecture like IMS, something like Keyless SSL could be one
way to support STIR - not outside the box at all. Standards along those
lines would be welcome.

But I think more broadly, the thing we mean when we talk about delegation
here in STIR encompasses something different than giving limited use of a
private key to a remote administrative domain. There are really different
trade offs to consider when there are multiple levels of delegation, when
the security association is formed by a call recipient discovering the
originator's credential rather than a standard HTTPS flow, and of course
when you're dealing with something other than just a DNS name that you
hope to delegate, as the properties of telephone numbers aren't the same.

Again, not to say that the proposed LURK work wouldn't have some
applicability here, for things like roaming and the transient "legitimate"
spoofing use cases that we sometimes entertain. But the overlap may turn
out to be narrow.

Jon Peterson
Neustar, Inc.

On 2/29/16, 9:38 AM, "stir on behalf of Eric Burger"
<[email-masked] on behalf of [email-masked]> wrote:

>For the people on the STIR list: there is a potential WG being discussed
>in BA, LURK, that is principally looking at the problem of a content
>provider somehow allowing a CDN to sign on their behalf so that HTTPS and
>browsers ³do the right thing.² If this sounds /similar/ to the STIR
>problem of delegated enterprise identity attestation, it should. See:
>and scroll down to ³Security² or search for ³LURK².
>For the people on the LURK list: I do not necessarily advocate for or
>assume the STIR problem is in scope. However, if you and they have a
>compelling case for why it should be in scope, or if it is kind of in
>scope but appropriate for a later rechartering once we finish the HTTPS
>(and possibly DTLS) use case, say so, too. If you are curious about what
>STIR is, see:

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 15:48:29 -0500

> https://www.ietf.org/mailman/listinfo/lurk

ISTM that these problems are different, because (I think) in the LURK 
case the identity is tied to the DNS naming hierarchy, while in STIR is 
is tied to E.164 numbers. So for LURK I would think there are solutions 
that naturally link to DNS, but for STIR that won't work.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Feb 2016 21:25:53 +0000

In addition, the SIP problem (STIR) problem has to manage what elements of the request are to be signed and validated. This does not appear to be a concern with the CDN case - it's just an HTTP cert. Thus, the intersection may well be "both use PK crypto"...

Henning

________________________________________
From: stir <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Monday, February 29, 2016 3:48 PM
To: [email-masked]
Subject: Re: [stir] Way outside the "box" use case

        Thanks,
        Paul

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir