Subject: [stir] Draft posted

From: Eric Rescorla <[email-masked]>
Date: Sun, 14 Jul 2013 17:37:10 -0700

Folks,

I have posted a -00 draft that provides a high-level description of
how one might do STIR out-of-band mode. I've deliberately
cut out a lot of the detail of the previous version and/or
relegated it to a separate section. The idea here is to look
at the big picture.

http://tools.ietf.org/html/draft-rescorla-stir-fallback-00

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 14 Jul 2013 22:38:09 -0400

Questions:

1) Section 4.1 says: "The question of how an entity is determined to have control of a given number is out of scope for this document."
But that's like half the problem, if not more.  Are you saying this fallback mechanism would re-use whatever authentication mechanism/model the in-band one uses?  I.e., it could come from some database of public keys, or some certificate signing authority chain, and either way it doesn't matter to this fallback thing?

I have a hard time understanding how that would work in practice.  The in-band mechanism's number authentication/credentials model has so far assumed private/public keys... and that realistically an end user/device wouldn't have a private key for the phone number, but that its service provider or carrier would instead.  So if the fallback is meant for carriers to be the "Alice" and "Bob", I would understand how the same authentication/credentials model of in-band could possibly work for fallback.  But not if Alice and Bob are truly end users/devices.

On the other hand, for a real end-user model, I could see very different authentication models used: for example by having Alice sign up for the CPS service, and part of the sign-up process being the CPS calling her phone or sending her an SMS, using the claimed phone number, and giving her some cookie to type/copy into the CPS' app to complete the sign-up process authentication.  After that her app would always have credentials to claim her number, though it would have to be renewed once a year or something.  And of course Bob would have to do the same, since you can't let just anyone ask if Alice is calling Bob.

But those types of details make a big difference for this stuff.  As I've said before on the list: if the fallback is meant for end-user smartphones/apps, I grok that something we define could be useful in *theory*; but I don't think we know if something we define would be useful in *practice*.  I don't know if it is actually needed by those who would deploy it, nor if it works the way they'd want it to work, with the features they'd want it to have.  In short: we don't have the right people involved in STIR for that type of thing.  We'd just be shooting in the dark.

2) How would this thing handle call-forwarding scenarios?  It's a nasty, ugly, brutal scenario even for in-band to handle... but I think it has to be handled. (as much as I wish it were otherwise)

3) What are the odds that Alice and Bob happen to use the same CPS service?  Would there be only one?  Who decides who that Highlander CPS is?  If it follows a "Federated Verification Service" model instead, where everyone uses their favorite CPS service and the CPS providers interconnect some way, why isn't that just either re-creating the PSTN using a protocol other than SIP, or even just re-creating the existing SIP service provider interconnection world of today?  I mean that's essentially what section 5.5 proposes to do.  Or worse, it's like VIPR all over again, without learning the lessons from VIPR's failure.  Maybe the fallback thing could be called "VIPRedux"? ;)

-hadriel

On Jul 14, 2013, at 8:37 PM, Eric Rescorla <[email-masked]> wrote:

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Jul 2013 14:58:36 -0700

Eric,

Comments in-line (or should I stash them on a web page, for possible 
retrieval...?)

> Abstract
>
>    A major challenge with RFC 4474-style identity assertions has been
>    that SIP operates in highly mediated and interworked environments.

Given the lack of implementation and deployment experience for RFC4474, 
there doesn't seem to be any public evidence of what specific problems 
the document has. So the opening attribution is problematic.

A reference like "RFC 4474-style" is quite ambiguous; there's no 
established practice or other way to know what it refers to in technical 
terms, and certainly not for folk outside this close-knit club.

I suspect that your core point hinges on something that is actually far 
more broadly applicable than just for that specification.  Perhaps as an 
alternative opening:

     Any SIP-based authentication mechanism that relies on the carriage 
of its information in SIP headers encounters a basic problem.  SIP 
typically operates in highly mediated and...

>    SIP requests may pass through gateways, policy enforcement devices or
>    other entities that receive SIP requests and effectively act as user
>    agents, re-initiating a request.  In these circumstances,
>    intermediaries may recreate the fields protected by the RFC4474
>    signature, making end-to end integrity impossible.  This document
>    describes a mechanism for two compliant endpoints to exchange
>    authentication data even in the face of intermediaries which remove
>    all additional call signaling meta-data or which translate from SIP
>    into protocols incapable of understanding identity meta-data (e.g.,
>    where one side is the PSTN).

> 1.  Introduction
...
>
>    While the core network of the PSTN remains fixed, the endpoints of
>    the telephone network are becoming increasingly programmable and
>    sophisticated.  Landline "plain old telephone service" deployments,

Not just the end-points.

All of the SIP-based components in the sequence ought to be equally 
programmable, certainly including SIP/PSTN gateways.

And gateways are the more typical place for performing channel-specific 
tunneling hacks like this.

>    especially in the developed world, are shrinking, and increasingly
>    being replaced by three classes of intelligent devices:  smart
>    phones, IP PBXs, and terminal adapters.  All three are general
>    purpose computers, and typically all three have Internet access as
>    well as access to the PSTN.  This provides a potential avenue for
>    building an authentication system that changes only the endpoints
>    while leaving the PSTN intact.

A benefit of, instead, placing the function in gateways is that it is 
only active when it is needed and by the relatively few nodes that need 
the special capability.  So this works for more users, as indicated by 
your second example, below.

> 3.  Architectural Options
...
>    There are roughly two plausible dataflow architectures for the CPS:
>
>
>
> Rescorla                Expires January 14, 2014                [Page 5]
> 
> Internet-Draft             Caller-ID Fallback                  July 2013
>
>
>    o  The callee registers with the CPS.  When the caller wishes to
>       place a call to the callee, it sends the CPR to the CPS which
>       forwards it to the callee.
 >
>    o  The caller stores the CPR with the CPS at the time of call
>       placement.  When the callee receives the call, it contacts the CPS
>       and retrieves the CDR.

The caller actions is the same for both.

The difference is simply a push (forwarding) vs. pull (retrieving) model 
for the callee-side of things.  Yes?

>    While the first architecture is roughly isomorphic to current VoIP
>    protocols, it shares their drawbacks.  Specifically, the callee must
>    maintain a full-time connection to the CPS to serve as a notification
>    channel.

That depends upon what is registered.  If a contact-me-at entry is 
registered, it does not require maintaining an open connection, does it?

>    This comes with the usual networking costs to the callee
>    and is especially problemtatic for mobile endpoints.  Thus, we focus
>    on the second architecture in which the PSTN incoming call serves as
>    the notification channel and the callee can then contact the CPS to
>    retrieve the CPR.

These don't have to be mutually exclusive.

Forwarding can be a performance optimization, available if the callee 
has registered, with pull (storage awaiting retrieval) is the default.

> 4.  Strawman Architecture
>
>    In this section, we discuss a strawman architecture along the lines
>    described in the previous section.  This discussion is deliberately
>    sketchy, focusing on broad concepts and skipping over details.  The
>    intent here is merely to provide a rough concept, not a complete
>    solution.
>
> 4.1.  Phone Number Authentication
>
>    We start from the premise that each phone number in the system is
>    associated with a set of credentials which can be used to prove
>    ownership of that number.  For purposes of exposition we will assume

Prove 'ownership' or prove 'assignment'?

>    that ownership is associated with the endpoint (e.g., a smartphone)
>    but it might well be associated with a gateway acting for the
>    endpoint instead.  It might be the case that multiple entities are
>    able to act for a given number, provided that they have the
>    appropriate authority.  The question of how an entity is determined
>    to have control of a given number is out of scope for this document.
>
> 4.2.  Call Placement Service
...
>    Once Alice has stored the CPR, she then places the call to Bob as
>    usual.  At this point, Bob's phone would usually ring and display
>    Alice's number (+1.111.111.1111), which is provided by the usual
>    caller-id mechanisms (i.e., the CIN field of the IAM).  Instead,
>    Bob's phone transparently contacts the CPS and requests any current
>    CPRs from Alice.  The CPS responds with any such CPRs (assuming they
>    exists).  If such a CPR exists, he can then present the callerid
>    information as valid.  Otherwise, the call is unverifiable.  Note
>    that this does not necessarily mean that the call is bogus; because
>    we expect incremental deployment many legitimate calls will be
>    unverifiable

This 'Note' sentence is more significant than it's placement in the 
document would seem to indicate.  It goes to a core challenge to make 
any of these mechanisms useful.

>
> 4.3.  Security Analysis
>
>    The primary attack we seek to prevent is an attacker convincing the
>    callee that a given call is from some other caller C. There are two
>    scenarios to be concerned with:
>
>    o  The attacker wishes to simulate a call when none exists.

What does that mean?

>    o  The attacker wishes to substitute himself for an existing call as
>       described in Section 4.3.1

Neither of these sounds like the scenario that I thought I'd been 
hearing during the life of this mailing list:

    The attacker initiates a call, using a Caller-ID value for which 
they do not have authorization.

Confusion about this suggests that the wg charter needs to be explicit 
and clear about the threat vectors that are to be of concern for the wg 
effort.

>
>    If an attacker can inject fake CPRs into the CPS or in the
>
>
>
> Rescorla                Expires January 14, 2014                [Page 7]
> 
> Internet-Draft             Caller-ID Fallback                  July 2013
>
>
>    communication from the CPS to the callee, he can mount either attack.
>    In order to prevent this, either the communication to the CPS should
>    be secured in transport (e.g., with TLS) or the CPRs should be
>    digitally signed by the caller and verified by the callee
>    (Section 5.2.  For privacy and robustness reasons, both are

      both are -> using both is

Anyhow, really?  Belts and suspenders?

With the object-based approach, signing isn't enough to provide privacy. 
  It needs confidentiality.  Since it's unlikely the caller and callee 
information will be encrypted, it won't provide meta-data privacy even then.

If object-based authentication is performed, TLS provides no value-add 
for authentication.

>    preferable.  In particular, if only transport security is used, then
>    a compromised CPS can forge call origination information.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Jul 2013 22:32:48 -0700

> Comments in-line (or should I stash them on a web page, for possible

Sure, if you like.

> there doesn't seem to be any public evidence of what specific problems the
> document has. So the opening attribution is problematic.
>
>     Any SIP-based authentication mechanism that relies on the carriage of
> its information in SIP headers encounters a basic problem.  SIP typically
> operates in highly mediated and...
>

Thanks. I'll take this under advisement for a future revidion.

> A benefit of, instead, placing the function in gateways is that it is only
> active when it is needed and by the relatively few nodes that need the
> special capability.  So this works for more users, as indicated by your
> second example, below.
>

I'm not sure what you're objecting to here. Is it just that you would like
me to
namecheck gateways earlier on?

> for the callee-side of things.  Yes?

Yes.

> registered, it does not require maintaining an open connection, does it
>

I'm not sure I follow what you're suggesting.

> Forwarding can be a performance optimization, available if the callee has
> registered, with pull (storage awaiting retrieval) is the default.
>

That might or might not work.

 4.  Strawman Architecture
> Prove 'ownership' or prove 'assignment'?

I'm happy to use "assignment" here. Perhaps there's some even more precise
term that we could be using, like "authorization to use".

> document would seem to indicate.  It goes to a core challenge to make any
> of these mechanisms useful.
>

I've been sort of hoping there would be some meta-document where this
could be placed more prominently.

>>    o  The attacker wishes to simulate a call when none exists.

It means convincing the victim that there is a call from someone to him
when in fact there is not (and presumably that the call that the victim
is currently answering is that call).

I.e., it's the threat you're suggesting is the primary purpose of the WG
below. Sorry if the phrasing was confusing.

> Neither of these sounds like the scenario that I thought I'd been hearing
> during the life of this mailing list:
>
>    The attacker initiates a call, using a Caller-ID value for which they
> do not have authorization.
>
> Confusion about this suggests that the wg charter needs to be explicit and
> clear about the threat vectors that are to be of concern for the wg effort.
>

Well, I think that's always valuable, but I think in this case it's
primarily
an issue of phrasing, since this is the first threat I am mentioning above.

> Anyhow, really?  Belts and suspenders?

Yes.

> information will be encrypted, it won't provide meta-data privacy even then.

I'm not taking a position on whether it's likely or not. As you no doubt
noticed,
this document discusses a mechanism for doing just that, so, no, I don't
think
it has probability 0.

> If object-based authentication is performed, TLS provides no value-add for
> authentication.
>

Not so. It makes anti-replay far easier in threat environments where you
trust the CPS.

-Ekr