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

["Elwell, John" <john.elwell at siemens.com>]

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> Behalf Of Dan Wing
> Sent: 29 October 2008 18:45
> To: 'Victor Pascual Ávila'
> Cc: sip at ietf.org
> Subject: Re: [Sip] submission of a new I-D: "Dialog Event 
> foRIdentityVErification"
> 
> 
>  
> 
> > -----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.
[JRE] I agree. This must include networks that contain B2BUAs/SBCs.

John
_______________________________________________
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