Re: [stir] Do we agree on the basics?

["Rosen, Brian" <[e-mail]>]

Of course, like most of us, you are an engineer, so you want to see that there is at least one solution that could work before you even want to see something in a charter.  So, EKR proposed one solution where the source writes a data record in a database encrypted for the termination.  All that depends on is the source and destination identities.  Ignoring whether you think we can deploy it, it does solve the problem.

I'll give you the guts of another solution:  The SIP-> SS7 GW writes a record with Called and Calling party TNs, and the SIP headers.  The SS7-SIP GW searches for a record with the same called and calling TNs, within a short time frame, and retrieves the SIP headers, which it uses to populate its outgoing message, effectively restoring the signature and the elements that were used when creating it.  Ignoring whether you think we could deploy it, it also solves the problem, but only in a more restricted set of situations.

There are all sorts of trust issues, cert distribution issues, privacy issues, business model issues, and a host of other stuff, but either of these solutions would work.  In this thread, I'd like to stay away from discussing those issues - I'm only trying to convince you that there are reasonable engineering solutions that would work.  Once we have a WG, we can work out the issues.  In the end, that might fail, but we're starting from  reasonable engineering base I think.

Brian
On Jun 19, 2013, at 10:18 AM, Michael Hammer <[e-mail]> wrote:

> The question of whether this works with SS7 in the path is a key one.
> That was part of the reason I was concerned about doing both E.164 and email
> identities at the same time.
> 
> I am not buying the out-of-band, not connected to the current state of the
> received signaling message, yet.
> If the signaling message arrives with different elements, how do I know that
> it is the same thing that is being signed out of band?
> Versus an imposter?
> 
> Mike
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> PFAUTZ, PENN L
> Sent: Wednesday, June 19, 2013 10:06 AM
> To: Rosen, Brian; [e-mail]
> Subject: Re: [stir] Do we agree on the basics?
> 
> Brian:
> I think this is a helpful summary to keep us on track; thanks for posting
> it. I do wonder if the fifth point, about handling SS7 in the middle may be
> too ambitious. My own belief is that the best we can hope to achieve is a
> solution in the post PSTN transition where we are end-to-end IP. While there
> is SS7 in the middle, there will still likely be SS7 at the beginning or at
> the end of some calls and I don't see us fixing those cases. So, I'll be
> happy if we just get the promised land right.
> 
> Penn Pfautz
> AT&T Access Management
> [phone]
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Rosen, Brian
> Sent: Wednesday, June 19, 2013 9:52 AM
> To: [e-mail]
> Subject: [stir] Do we agree on the basics?
> 
> A lot of our discussion is focussed on where certs are found.  I want to
> make sure that we agree on the basics, because where certs are found is
> pretty far down the list of things to agree on.
> 
> So, do we agree:
> 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The
> APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the
> call, because we believe that spoofing identity or non providing identity is
> the way the bad calls are being placed.
> 3. The METHOD we're going to use is to pick some data from the call and sign
> or encrypt it in a way that a downstream entity can verify that the
> information is valid 4. The CREDENTIALS we're going to use, for identities
> that are telephone numbers, is based on delegation of the number, rooted in
> the national numbering authority.  For identities that are domain based, the
> credentials are based on the domain entry in the DNS.
> 5. We think we need two MECHANISMS, an in-band mechanism that has the
> originating device or service provider signing information and carries the
> signature in the signaling.  The other is some out of band mechanism that
> involves some new database or service that gets written by the originating
> device or service provider and checked by some downstream entity.  The
> latter mechanism is needed to allow the identity to be assured even if the
> information or signature from the in band mechanism is lost (such as when
> the call goes through an SS7 hop).
> 6. The credentials (4) are the same in both mechanisms (5)
> 
> 
> That doesn't say things like where the certs are or what is signed, or what
> the out of band mechanism does.
> 
> So, I ask, do you agree with that?
> 
> Brian
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir