Re: [Sip] submission of a new I-D: "Dialog Event foRIdentityVErification"

["Dan Wing" <dwing at cisco.com>]

> -----Original Message-----
> From: Victor Pascual Ávila [mailto:victor.pascual.avila at gmail.com] 
> Sent: Wednesday, October 29, 2008 4:16 AM
> To: Dan Wing
> Cc: sip at ietf.org
> Subject: Re: [Sip] submission of a new I-D: "Dialog Event 
> foRIdentityVErification"
> 
> Hi Dan,
> Please, see my comments inline.
> 
> On Wed, Oct 29, 2008 at 4:42 AM, Dan Wing <dwing at cisco.com> wrote:
> >> 2008/10/28 Dan Wing <dwing at cisco.com>:
> >> > Here is another return routability check,
> >> > http://tools.ietf.org/html/draft-wing-sip-e164-rrc-01#section-3.1
> >> > (My I-D expired due to lack of interest.)
> >>
> >> It uses RFC 4474, certificates... is it really feasible in
> >> this real world?
> >
> > No, it doesn't use RFC4474.  The steps merely show where an RFC4474
> > signature could be performed.  If no RFC4474 signatures are
> > being created, or validated, those steps are the 'null operation'
> > (not performed).  Without those steps, it is remarkably similar
> > to DERIVE.
> >
> >> IMHO "Dialog Event foR Identity VErification" is the more feasible
> >> solution at the moment.
> >
> > The differences are minor.
> 
> The Return Routability Check (RRC) determines if a domain rightfully
> 'owns' an E.164 phone number, but DOES NOT prevent an attacker from
> presenting a forged "From" header field.
> 
> As an example:
> 
> INVITE sip:victor at tekelec.com SIP/2.0
> From: +14085551234 
> <sip:+14085551234 at iptel.org;user=phone>;tag=9fxced76sl
> To: Victor <sip:victor at tekelec.com>
> Call-ID: 3848276298220188511 at iptel.org
> Contact: <sip:attacker at pc1.attacker.com>
> Content-Type: application/sdp
> Content-Length: ...
> 
> [SDP not shown]
> 
> Where iptel.org owns the +14085551234 number.
> 
> Section 3.2:
> -The SUBSCRIBE should be immediately acknowledged
> -A NOTIFY should be immediately created and sent
> 
> 
> Moreover IMO:
> - it requires the use of signatures (or RFC4474): see 
> Sections 3, 3.1 and 3.2

As I said previously:  if there is no signature service, this is the null
operation.  The UA is competely incapable of causing or forcing its domain to
generate an RFC4474 signature, anyway, so it's impossible for a UA to
'require' such a signature.

> - it is defined to be used only with e164-based SIP URIs
> 
> In short, this is a good document but, as I mentioned before, ONLY
> determines if a domain rightfully 'owns' an E.164 phone number, it
> doesn't ask "are you calling me?"

Easily added; draft-wing-sip-e164-rrc-01 currently reads:

   3.2.  Authentication Service or Calling Endpoint Operation

   The steps described in this section can be performed by the
   authentication service or by the calling endpoint.

   The authentication service or the calling endpoint, upon receiving a
   SUBSCRIBE for the return-routability event package, performs the
   following steps:

   1.   The SUBSCRIBE should be immediately acknowledged with a 200 Ok
       ^
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   INSERT "If there is another active INVITE dialog, which has not 
           received its 200 Ok, then"

       message.
                ^
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      INSERT "If there is not another active INVITE dialog, an error
        response is sent (e.g., 4xx), and processing stops."

   2.  A NOTIFY should be immediately created, containing the same
       application/return-routability-nonce copied from the SUBSCRIBE.
       This NOTIFY contains a To and Request-URI which match the From of
       the SUBSCRIBE.

   3.  This NOTIFY is sent.

   4.  The RFC4474 authentication service, operating at the domain, will
       create a signature over the NOTIFY.  This is used by the remote
       domain's verification service (see Section 3.1).


I'm not interested in having a competing proposal, though, or arguing
nits about which 4xx response code is most appropriate.

We should be arguing about larger issues, such as the value of proving 
someone is actually originating a call.  Without that, we cannot have 
reliable whitelists or reliably blacklists, which are the foundations 
for authorizing incoming SIP requests.

I support draft-kuthan-sip-derive-00, and hope the WG can devote
time and energy to improving and standardizing it to work well
across a variety of networks.

-d

> Thanks a lot for your comments,
> -- 
> Victor Pascual Ávila
> 

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip