> -----Original Message-----
> From: Victor Pascual Ávila [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, October 29, 2008 4:16 AM
> To: Dan Wing
> Cc: [email protected]
> 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 <[EMAIL PROTECTED]> wrote:
> >> 2008/10/28 Dan Wing <[EMAIL PROTECTED]>:
> >> > 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:[EMAIL PROTECTED] SIP/2.0
> From: +14085551234 
> <sip:[EMAIL PROTECTED];user=phone>;tag=9fxced76sl
> To: Victor <sip:[EMAIL PROTECTED]>
> Call-ID: [EMAIL PROTECTED]
> Contact: <sip:[EMAIL PROTECTED]>
> 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to