Re: [stir] Draft STIR Charter

[Hala Mowafy <[e-mail]>]

Stephen,
If I understand your question correctly AND you're emulating the same ringing patterns that customers are used to in the PSTN, the called party would expect to see the caller ID before the second ring.  So, in effect, you have 2 sec ON (first ring) - 4 sec OFF (silence) to get that caller ID verified and delivered before the second ring (6 sec total).  That's in North America.  In the UK and other parts of the world the ringing cadence varies but I believe it is shorter (~ 3 seconds total).
So, all authorization transactions PLUS any other session setup time with the phone, etc., have to fit in those timeframes, even though you don't need those ring times for a SIP call - per se; you're just preserving the customer experience.

My question to the OCSP experts is:  what is an average OCSP query response time if we just stay within one country?  are we talking milliseconds or seconds?
Hala

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Stephen Farrell
Sent: Thursday, July 11, 2013 1:55 PM
To: Russ Housley
Cc: Richard Barnes; [e-mail]; Gonzalo Camarillo; Brian Rosen
Subject: Re: [stir] Draft STIR Charter


Hi Russ,

I think this looks pretty good. A few wordsmithing changes and a question below but I have one addition to suggest:

Somewhere this should say that the solution chosen needs to have an acceptable overhead at both signer and verifer or else it also won't be deployed. There may be some on here who could suggest indicative timing or networking constraints (e.g. not having to do ~5 OCSP transactions to possibly anywhere in the world) and if so, that'd be a good thing to include IMO.

On 07/11/2013 03:21 PM, Russ Housley wrote:
> Dear STIR Mail List Participants:
> 
> Brian and I have tried to pull together charter text based on the 
> discussion to date.
> 
> The closer we can get to consensus on the list before the BOF, the 
> more likely that we can get a WG shortly after Berlin.  To this end, 
> please review and comment on the attached text.  Brian and I will hold 
> the pen for updates to the text.
> 
> Russ
> 
> = = = = =
> 
> Name: Secure Telephone Identity Revisited (stir) Area: RAI
> 
> Chairs: TBD Area Advisor: Richard Barnes
> 
> Mailing list: [e-mail] To Subscribe:
> https://www.ietf.org/mailman/listinfo/stir
> 
> Over the last decade, a growing set of problems have resulted from the 
> lack of security mechanisms for attesting the origins of real-time 
> communications.  As with email, the claimed source identity of a SIP 
> request is not verified, and this permits unauthorized use of source 
> identities as part of deceptive and coercive activities, such as 
> robocalling (bulk unsolicited commercial communications), vishing 
> (voicemail hacking, and impersonating banks) and swatting 
> (impersonating callers to emergency services to stimulate unwarranted 
> large scale law enforcement deployments).  This working group will 
> define a deployable mechanism to validate the identity of the calling 
> party that can be verified by entities in the path of a call.
> 
> SIP is one of the main VoIP technologies used by parties that want to 
> present an incorrect origination.  A number of previous efforts have 
> tried to secure the origins of SIP communications, including RFC 3325, 
> RFC 4474, and the VIPR working group. To date, however, true 
> validation of the source of SIP calls has not seen any appreciable 
> deployment.  Several factors contributed to this lack of success,
> including: failure of the problem to be seen as critical at the time; 
> lack of any real means of asserting authority over telephone numbers; 
> misalignment of the mechanisms proposed by RFC 4474 with the complex 
> deployment environment that has emerged for SIP; lack of end-to-end 
> SIP session establishment; and inherent operational problems with a 
> transitive trust model.
> 
> Initially, the working group will specify an in-band mechanism to 
> authenticate the originator of a SIP session where the identity being 
> authenticated is a telephone number and the session is established 
> with SIP end to end.  The working group will consider choices for 
> protecting the identity information and the credentials used, but will 
> likely be similar to the methods described in RFC 4474, which employs 
> a signature over a set of information in the SIP headers using a 
> credential assigned to the identity.

I suggest replacing the above with

"will likely be based on a digital signature mechanism that is cryptographically similar to the one described in RFC 4474 and where the signature continues to be represented in SIP headers."

Saying "methods" and 4474 is a bit vague and could be read to mean "s/mime-based" or "cms based" or "x.509 based" whereas what I think we want is just to say its a signature.

Similarly "assigned to the identity" is very ambiguous and probably better just omitted for now.


>  In order to be
> authoritative, credentials used with this mechanism will be derived 
> from existing telephone number assignment and delegation models.

No specific change suggested but are we using credential here to mean the private key or a (set of) TN(s) associated with a public key? I think it ought be the latter.

> That is, when a telephone number or range of telephone numbers is 
> delegated to an entity, a credential will accompany such delegation.

That's problematic with either definition of credential. I think it'd be ok to say:

  That is, when a telephone number or range of telephone numbers is
  delegated to an entity, relevant credentials will be generated (or
  modified) to reflect such delegation.

> The mechanism must allow parties who are not delegated a telephone 
> number, but are preauthorized by the entity who is delegated the 
> number, to place calls using the identity.

No specific change suggested, but I've always wondered if this requirement is real. I'd argue enough good would be done without try to stretch for this. But I defer to those who know more about the application.

> Expansion of the
> authentication mechanism to identities using the user@domain form 
> should be considered in the initial design.

To be honest, I didn't read that thread (one too many:-) but I'm surprised that this is to be part of the initial design. But "considered" is sort of weasel-wordy so I'm not sure what's really meant - what is "considered" meant to mean here?

Cheers,
S.

> After completing the SIP
> end to end solution, the working group will consider session 
> establishment where there are one or more non-SIP hops, most likely 
> using an out-of-band authentication mechanism.  However, the in-band 
> and out-of-band mechanisms should share as much in common as possible, 
> especially the credentials.
> 
> The working group will coordinate with the Security Area on credential 
> management.
> 
> The working group will coordinate with other working groups in the RAI 
> Area regarding signaling through existing deployments, including 
> INSIPID.
> 
> Authenticated identity is closely linked to privacy, and one 
> frequently comes at the cost of the other. This working group is not 
> chartered to mandate the presence of identity in SIP requests, and to 
> the extent feasible it will find privacy-friendly solutions that leak 
> minimal information about calls to third parties.
> 
> Input to working group discussions shall include:
> 
> Private Extensions to the Session Initiation Protocol (SIP) for 
> Asserted Identity within Trusted Networks RFC 3325
> 
> Enhancements for Authenticated Identity Management in the Session 
> Initiation Protocol (SIP) RFC 4474
> 
> Secure Call Origin Identification
> http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00
> 
> Secure Origin Identification: Problem Statement, Requirements, and 
> Roadmap
> http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00
> 
> Authenticated Identity Management in the Session Initiation Protocol
> (SIP)
> http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00
> 
> The working group will deliver the following:
> 
> - A problem statement detailing the deployment environment and 
> situation that motivate work on secure telephone identity
> 
> - A mechanism document describing the SIP end-to-end with telephone 
> number-based identities
> 
> - A document describing the credentials required to support secure 
> telephone identity
> 
> - A fallback mechanism to allow out-of-band identity establishment 
> during call setup
> 
> Milestones
> 
> Sep 2013   Submit problem statement for Informational Nov 2013
> Submit RFC4474bis for Proposed Standard Feb 2014   Submit credential
> specification for Proposed Standard Jun 2014   Submit fallback for
> Proposed Standard
> 
> _______________________________________________ stir mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/stir
> 
> 
_______________________________________________
stir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/stir