Re: [stir] Draft posted (draft-rescorla-stir-fallback-00)

[Eric Rescorla <[e-mail]>]

On Mon, Jul 15, 2013 at 2:58 PM, Dave Crocker <[e-mail]> wrote:

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

Sure, if you like.



>
>  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...
>

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



>
>>    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.
>

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


>
>  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?
>

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
>

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



>     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.
>

That might or might not work.


 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'?
>

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



>
>     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.
>

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



>
>> 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?
>

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.



>     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.
>

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.



>
>>    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?
>

Yes.



> 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.
>

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