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

[Dave Crocker <[e-mail]>]

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