Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 12 Jul 2006 17:26:35 -0400

> Many WGs have something like it. We need a draft with the 
> threats/attacks and possibly how the (3?) proposed security 
> methods deal with them.

Yes, so first step is to define the possible threats/attacks as noted in
the meeting.  We had a volunteer afterwards who we're going to chat with
to see if they can make a contribution on this.

Then we can figure out, for each of the supposed threats/attacks, what
the proposed methods are.  So it's a two step process, which may take a
bit more time but I think we'll end up with a better long-term result.

So, we'll get the ball rolling on the first step soon...

Thanks
Jason

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 12 Jul 2006 17:29:32 -0400

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> I think we use the methods we have used in most of the sippish specs:
> 
> It's mandatory to IMPLEMENT TLS between peers (presumably 
> peer proxies).
> It's mandatory to DEPLOY some kind of mutual authentication, 
> which does not have to be TLS.  

Yes, I think that is a fair statement and one we noted in the session
(sorry we missed having you there!).
 
Jason

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 13 Jul 2006 13:11:22 -0400

Agree.  It's a balancing act.

Having a default is only there to assure that disjoint sets don't occur.

Mike

> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 12:21 PM
> To: Reinaldo Penno; David Schwartz; [email-masked]
> Subject: Re: [Speermint] TLS, etc - Local-policy versus WG mandate
> 
> >In other words, a federation does not need only to provide a common 
> >denominator but can also provide more choices as the sum of 
> the parts.
> 
> >Wouldn't that be valuable?
> 
> maybe, but we also should obey KISS
> 
> Richard
> 
> ________________________________
> 
> Von: Reinaldo Penno [mailto:[email-masked]]
> Gesendet: Do 13.07.2006 18:08
> An: Michael Hammer (mhammer); David Schwartz; Uzelac, Adam; 
> [email-masked]
> Betreff: RE: [Speermint] TLS, etc - Local-policy versus WG mandate
> 
> 
> 
> inline
> 
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Thursday, July 13, 2006 9:01 AM
> > To: David Schwartz; Uzelac, Adam; [email-masked]
> > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate
> >
> > Inline...
> >
> > > From: David Schwartz [mailto:[email-masked]]
> > > Sent: Thursday, July 13, 2006 10:05 AM
> > > To: Uzelac, Adam; [email-masked]
> > > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate
> > >
> > > So here are my two cents (just repeating what I said at 
> the session)
> > >
> > > My claim which was not directly rebuffed is why authentication is 
> > > any different than any other policy issue.
> > > As far as I can tell there are 2 not 3 issues that need to be 
> > > resolved for peering to occur.
> > >
> > > 1. Where is the other side
> > > 2. Can we communicate
> > >
> > > If we focus on the second issue it includes things like
> > >
> > > * Will the other side even accept a call from me
> > > * Assuming other side will accept my calls
> > > *    Which authentication mechanism do I use for this
> > > communication- if
> > > any
> > > * what are the ground rules for communication (e.g. 
> specific codecs)
> > > * etc.
> > >
> > > I think of federations as shared namespace NOT policy.
> >
> > I disagree.  My view of federation is having a shared policy, ie.
> rules
> > of engagement some of the most important ones center around security
> and
> > trust, and independent of namespaces.
> >
> > The policy is about having a common denominator, such that you are 
> > guaranteed that you share at least one code, share at least one
> security
> > mechanism, in order to assure that the communication will 
> go through.
> >
> >
> > > Federations are comprised of one namespace and multiple policy 
> > > federations describing the relationships between the 
> members. This 
> > > is why for the life of me I cannot understand why it is 
> not ok with 
> > > me to peer with A via TLS and with B with IPSec and with 
> 3 with no 
> > > authentication at all.
> > > Authentication is just a policy decision and should NOT 
> be mandated.
> >
> > If more than one mechanism is agreed to be supported, there is not 
> > reason that you couldn't do that.
> >
> >
> > > I know everybody will yell at this but to me making ANY security 
> > > mechanism mandatory is tantamount to making a minimal codec set 
> > > mandatory and we know how this list reacted when that was 
> proposed.
> >
> > Mandatory to support, not necessarily use.
> >
> >
> > > If any member is dumb enough not to implement TLS or 
> IPSec or some 
> > > other security mechanism he will soon find that no one 
> will accept 
> > > traffic from him and implement it then.
> >
> > Even if A did only TLS and B did only IPSEC, what would be the point
> of
> > them being in a federation together?
> >
> >
> [[Reinaldo]]
> 
> For this very reason you stated. A can be reached by TLS 
> directly or through B for those that implement IPSec.
> 
> In other words, a federation does not need only to provide a 
> common denominator but can also provide more choices as the 
> sum of the parts.
> 
> Wouldn't that be valuable?
> 
> > > We do not have to mandate not being STUPID.
> >
> > But, we do need to mandate certain things so that we don't do
> something
> > stupid.  :)
> >
> > Mike
> >
> >
> > >
> > > Cheers,
> > >
> > > David
> > >
> > > From: Uzelac, Adam [mailto:[email-masked]]
> > > Sent: Wednesday, July 12, 2006 9:44 PM
> > > To: [email-masked]
> > > Subject: [Speermint] TLS, etc - Local-policy versus WG mandate
> > >
> > > Pertaining to the "To TLS or not TLS" discussion in the 
> WG sessions, 
> > > time didn't permit a proper tomato tossing session at the 
> WG session 
> > > - but one comment was made about mandating such things as 
> TLS, etc - 
> > > to which a rebuttal was made that the type of authentication and 
> > > authorization used and implemented is an issue of local 
> policy and 
> > > therefore shouldn't be mandated.
> > >
> > > For fear of starting a "great taste" versus "less filling"
> > > argument - Let me start this way....I agree with what 
> appeared to be 
> > > consensus in the WG session that there needs to be first 
> a Discovery 
> > > procedure, then an Authentication procedure, and finally 
> connecting 
> > > the call.  The methods upon which each step along the way is done 
> > > should not to so narrow as to exclude popular and in some cases 
> > > widely adopted methods.
> > > Speermint should provide the BCP - but does that really need to 
> > > exclude other plausible and practical models?  It's important to 
> > > note that I believe TLS is the most appropriate, practical and 
> > > logical approach.  I also believe the there are valid reasons for 
> > > other approaches to authenticate.  The same holds true 
> for methods 
> > > of discovery.
> > >
> > > So the question for the group and possibly some guidance from the 
> > > chairs here?!?!? - Should an undertaking to determine 
> what should be 
> > > determined via local policy versus mandated via 'MUSTs' 
> be done?  Is 
> > > this a section for the requirements doc?
> > >
> > > I would like to thank Rohan for bringing this issue to 
> the forefront 
> > > in a lightning-rod manner!! ;)
> > >
> > > Regards,
> > >
> > > Adam
> > >

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 13 Jul 2006 07:45:43 -0400

That is a good first step, thanks.

Mike

> Sent: Wednesday, July 12, 2006 5:04 PM
> To: Michael Hammer (mhammer); Brian Rosen; [email-masked]
> Mike,
> I am not sure about an agreed upon way to address security 
> concerns, but there was a request from the WG chairs that a 
> document specifying threats be compiled.  Dan York from Mitel 
> offered to participate leveraging his work from www.voipsa.org.
> 
> Adam
> 
> Sent: Wednesday, July 12, 2006 4:42 PM
> To: Brian Rosen; Uzelac, Adam; [email-masked]
> Please refresh my memory.  
> 
> Was there going to be a separate document that addresses 
> security on the peering interface?
> 
> Or, is this to be a security section in each of the documents 
> that peel the onion, starting with discovery, with perhaps 
> the policy discovery layer of the onion saying that 
> federations should establish security policy and here are the 
> minimum requirements that such policies hopefully support, 
> with other layers saying signaling/media follow the security 
> policy, whatever that is?
> 
> Mike
> 
> 
> > Sent: Wednesday, July 12, 2006 3:22 PM
> > To: 'Uzelac, Adam'; [email-masked]
> > Due to the last minute schedule change, I was unable to attend the 
> > meeting, but perhaps we now have enough consensus to write down the 
> > answer.
> > 
> > It's mandatory to IMPLEMENT TLS between peers (presumably peer 
> > proxies).
> > It's mandatory to DEPLOY some kind of mutual authentication, which 
> > does not have to be TLS.
> > 
> > I suspect that we want to actually say that the federation 
> establishes
> 
> > a particular authentication standard that all members use.
> > 
> > Brian
> > 
> > 
> > 
> > Sent: Wednesday, July 12, 2006 2:44 PM
> > To: [email-masked]
> > Pertaining to the "To TLS or not TLS" discussion in the WG 
> sessions, 
> WG session -
> > but one comment was made about mandating such things as 
> TLS, etc - to 
> > which a rebuttal was made that the type of authentication and 
> > authorization used and implemented is an issue of local policy and 
> > consensus in the WG session that there needs to be first a 
> Discovery 
> > procedure, then an Authentication procedure, and finally connecting 
> > should not to so narrow as to exclude popular and in some 
> cases widely
> 
> > adopted methods.
> > exclude other plausible and practical models?  It's 
> important to note 
> > that I believe TLS is the most appropriate, practical and logical 
> > approach.  I also believe the there are valid reasons for other 
> > approaches to authenticate.  The same holds true for methods of 
> > discovery.
> > 
> > chairs here?!?!? - Should an undertaking to determine what 
> should be 
> > determined via local policy versus mandated via 'MUSTs' be 
> done?  Is 
> > I would like to thank Rohan for bringing this issue to the 
> forefront

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 17 Jul 2006 14:03:24 -0400

David,

We may be talking past each other based on when and how we envision
various policies being applied.  I could see some policies being applied
before the first INVITE gets sent and some after.  

Guess I'll have to wait for your use case to better understand where you
are coming from.  

Hopefully, it covers the nature of the data session and whether you
expect re-INVITEs, REFERs, UPDATEs, BYEs and such to occur in only one
direction, or whether you are referring to uni-directional media.  I
could read all sorts of things into the words and be quite wrong about
what you intend.
Mike

> Sent: Monday, July 17, 2006 1:27 PM
> To: Michael Hammer (mhammer); Uzelac, Adam; [email-masked]
> Hi Mike
> The opposite is true. I contend that the CAN is limited to NO 
> SECURITY basic SIP signaling capability. This is my objection 
> to the inclusion of things like TLS in a BASE spec. The MAY 
> is exactly the point I am focusing on only I am calling the 
> mechanism to determine the MAY -- "policy". The MAY includes 
> security, tome of day and just about any other rule that may 
> prevent one party from reaching another even though on the 
> base signaling level this is possible.
> 
> Cheers,
> 
> David
> 
> Sent: Monday, July 17, 2006 5:56 PM
> David,
> I am not sure I understand your use case yet, but would like 
> to ask if this intertwining the policy layer and the 
> signaling layer.  In other words,  whether one party can 
> communicate and whether they may communicate are two 
> different things.  There are many PSTN services, such as the 
> Closed User Group (CUG) feature that can be handled at the 
> signaling layer independent of the fact that one could make 
> the call and it would go through absent the application of 
> this feature.  Overlaying these two means that one could be 
> using all the right technical mechanisms and "can" call, but 
> the service feature causes the call to be rejected.
> 
> You seem to be reinventing the CUG feature via the federation policy.
> 
> Mike
>  
> 
> > Sent: Monday, July 17, 2006 6:06 AM
> > To: Michael Hammer (mhammer); Uzelac, Adam; [email-masked]
> > I seem to be getting a lot of heat for suggesting the 
> independence of 
> > namespace resolution and policy (including security). What I keep 
> > hearing is that there needs to be a minimal set of requirements 
> > (a.k.a.
> > Prime Directives :-) ) for communication (hence the security
> > requirements) for "what is the point of knowing where the 
> other party 
> > is it cannot be reached".
> > 
> > By extension this model MUST assume that communication in a 
> federation 
> > MUST be symmetric. Both parties MUST be able to initiate 
> communication 
> > to each other. If not, than the one who cannot initiate, in essence 
> > "knows" where the other party is but cannot communicate, hence 
> > violating one of the prime directives of federations.
> > 
> > This is downright silly. As you will see in the "use case" 
> I am in the 
> > process of writing there are complete valid models of federations 
> > where this is not the case. Take for example the case of a "closed" 
> > club where all members want to RECEIVE traffic only from members of 
> > this closed club. One or more of these members may want to 
> > additionally SEND traffic to a wider audience while still receiving 
> > traffic from only the closed club (why this would happen is 
> discussed 
> > in my use case draft). The closed members would need to 
> know where the 
> > "open" members are to initiate this communication. By sharing 
> > namespace this can be accomplished since all numbers 
> (closed and open) 
> > can be known to all members (closed and open) and yet calls 
> > originating in closed network would be allowed out based on 
> receiving 
> > member policy and calls originating in open network would not be 
> > allowed into closed club, again, based on receiving party policy.
> > 
> > While you may argue that this is a case of peering between two 
> > federations the underlying model still mandates asymmetric 
> signaling 
> > capabilities and hence my preference for a federation definition 
> > comprised only of a single shared namespace with provisions for 
> > sharing/informing/negotiating policy.
> > 
> > Cheers,
> > 
> > David
> > 
>

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Tue, 25 Jul 2006 14:53:03 -0500

Okay, we will make it creatively interoperable and flexible. 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 2:31 PM
To: Khan, Sohel Q [CTO]; 'Daryl Malas'; 'David Schwartz'
Cc: [email-masked]; 'Uzelac, Adam'
Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate

I'm sorry, but standards are nearly the exact opposite of "creativity
and flexibility".  We create standards to be interoperable.  They
severely restrict what you can do so that there are no surprises, your
implementation matches the other guy's.

If you want creativity and flexibility, be my guest - start a peering
service, define your interfaces any way you want and see who comes.  Use
all the creativity and flexibility you can.

If you want interoperable implementations, then we specify, with very
little flexibility, and almost no creativity, what to do.

Options in protocols are BAD.  The best protocols have only one way to
do something, and everyone implements it the same way.  The worst
protocols have elaborate negotiation mechanisms so that everyone's
favorite choices have standards coverage.

Bah on your creativity and flexibility  :)

Brian

> From: Khan, Sohel Q [CTO] [mailto:[email-masked]]
> Sent: Tuesday, July 25, 2006 3:03 PM
> To: Daryl Malas; David Schwartz
> Cc: [email-masked]; Uzelac, Adam
> Daryl Malas [mailto:[email-masked]] wrote:
> 
> >My primary rebuttal is this can be solved in many ways...should we
> define all of these, which
> >would simply take away an operator's own routing creativity and
> flexibility?  ...or, should we
> >define principle functions, which may be implemented to enable 
> >peering
> in manners that enable
> >greater creativity and flexibility in peering?
> 
> We should define principle functions that would allow creativity and 
> flexiblity in peering.
> 
> Sohel Khan, Ph.D.
> Technology Strategist
> Sprint-Nextel
> 913-794-1470 (office)
> 913-486-3145 (cell)
> 
> 
>