Subject: Re: [tram] STUN hash agility

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 1 Apr 2014 12:15:59 +0000

> -----Original Message-----
> From: Simon Perreault [mailto:[email-masked]]
> Sent: Friday, March 28, 2014 6:17 PM
> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko; Jonathan Lennox
> Cc: [email-masked]
> Subject: Re: [tram] STUN hash agility
> 
> Oooooh! I love playing the devil's advocate... :)

:)

> 
> Le 2014-03-28 05:16, Tirumaleswar Reddy (tireddy) a écrit :
> > 1)TURN Server has to maintain the {username/realm/password} database
> > just like the AD server which is an overhead.
> 
> Are you assuming that the TURN server cannot query the AD server instead
> of maintaining a duplicate database ?

TURN server can query the AD server. But this will be not be the typical request/response used, in this case the request must contain (username, realm) asking for the password.

> 
> In any case, database replication is easy and well understood. You need
> to have *lots* of accounts for e.g. dead-simple MySQL replication to not
> be sufficient.

Or the TURN server can establish connection with remote RDMS server and send query to get the password.

> 
> > 2)In a large Enterprise Network (for e.g. consider a large service
> > company) where NNN number of new users join, MMM users leave every day.
> > It seems difficult to manage this credential database on the TURN server
> > to be in sync with the AD.
> 
> Really? MySQL replication (for example) is dead simple.
> 
> > 3)If each branch office in an large enterprise network wants to deploy
> > TURN servers, then the cost of TURN server includes additional storage
> > space and operational issues which may be a concern of the
> > I.T.
> 
> I doubt this very much. You would need *lots* of user accounts for the
> password database to not fit on any regular-sized hard drive.
> 
> About operations: once again, database replication is well understood
> and very common.

Database replication will work but it's an overhead in the above use case. In service based companies, where onboarding/off-boarding of users on daily basis is frequent, this would call for frequent database replication.  If branch offices  want TURN server to be co-located with a router, it may not even have hard-drive to store this info. With the current limitation, software upgrade of the router to support TURN server will not be sufficient. I.T will also have to purchase routers which come up hard drive. 

Further a small branch/sales office of an Enterprise network may have only few hundred users in that site, it's an over-head to replicate the credentials of the entire org to this small site.

> 
> > 4)AD server maintained in the Data Center usually has better physical
> > security than branch offices - what if someone breaks into the branch
> > office and steals all the username + password ? (I am assuming the
> > username, password are the same credentials used to access other
> > critical enterprise resources)
> 
> Now this I totally buy. We need something better than
> MD5(username:realm:password).

Cheers,
-Tiru

> 
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 10 Apr 2014 10:26:36 +0000

> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Tuesday, April 08, 2014 12:41 AM
> To: [email-masked]
> Isn't that problem more in the category of 3rd party auth improvements than
> hash agility?
> Or are you suggesting that the hashing mechanism to be used on the
> authentication information could make a difference in terms of whether or not
> it was viewed as violating that policy ?

Though 3rd party authorization does not have the problem of hash agility, I am not sure if that means first party authentication can be removed. TURN servers provided by Application servers may want to only use 3rd party authorization. But first party authentication may be required for Enterprise use cases. For example considering the requirement discussed in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.1 where it is mandatory to for the Enterprise to use TURN for all external RTCWEB communication. The auditing policy requires TURN server should be aware of endpoints username/realm for logging purpose.

If the Enterprise I.T decides to go with a cloud vendor either offering TURN servers or decides to setup it's TURN servers in a public cloud. The authentication mechanism requires that either the TURN server should know the user credentials or alternatively gets the credentials from the AD server deployed in the Enterprise Data Center. But both mechanisms may not acceptable since it requires the credentials to be stored outside the Enterprise premises. The  policy violations with the current authentication mechanism would be that:

* Data is extremely sensitive and the management cannot risk hosting it on public infrastructure but at the same time wants to leverage cloud services
* Local and national laws prohibit data from leaving the country the company is domiciled in
* The business is not confident of entrusting data to a third party

-Tiru

> 
> --Brandon
> 
> On 04/07/2014 02:33 PM, Tirumaleswar Reddy (tireddy) wrote:
> > The other point that we missed to discuss is that if Enterprise wants to
> leverage the services of cloud (for e.g. Hybrid cloud) for deploying TURN servers.
> Enterprise information security policy may not permit credentials to be stored
> outside it's domain.
> >
> > Cheers,
> > -Tiru
> >
> >> From: Tirumaleswar Reddy (tireddy)
> >> Sent: Tuesday, April 01, 2014 5:45 PM
> >> To: 'Simon Perreault'; Oleg Moskalenko; Jonathan Lennox
> >> Cc: [email-masked]
> >> Subject: RE: [tram] STUN hash agility
> >>
> >>>> 1)TURN Server has to maintain the {username/realm/password}
> >>>> database just like the AD server which is an overhead.
> >>>
> >>> Are you assuming that the TURN server cannot query the AD server
> >>> instead of maintaining a duplicate database ?
> >>
> >> TURN server can query the AD server. But this will be not be the
> >> typical request/response used, in this case the request must contain
> >> (username, realm) asking for the password.
> >>
> >>>
> >>> In any case, database replication is easy and well understood. You
> >>> need to have *lots* of accounts for e.g. dead-simple MySQL
> >>> replication to not be sufficient.
> >>
> >>>> It seems difficult to manage this credential database on the TURN
> >>>> server to be in sync with the AD.
> >>>
> >>>> 3)If each branch office in an large enterprise network wants to
> >>>> deploy TURN servers, then the cost of TURN server includes
> >>>> additional storage space and operational issues which may be a
> >>>> concern of the I.T.
> >>>
> >>> I doubt this very much. You would need *lots* of user accounts for
> >>> the password database to not fit on any regular-sized hard drive.
> >>>
> >>> About operations: once again, database replication is well
> >>> understood and very common.
> >>
> >> Database replication will work but it's an overhead in the above use
> >> case. In service based companies, where onboarding/off-boarding of
> >> users on daily basis is frequent, this would call for frequent
> >> database replication.  If branch offices want TURN server to be
> >> co-located with a router, it may not even have hard- drive to store
> >> this info. With the current limitation, software upgrade of the
> >> router to support TURN server will not be sufficient. I.T will also have to
> purchase routers which come up hard drive.
> >>
> >> Further a small branch/sales office of an Enterprise network may have
> >> only few hundred users in that site, it's an over-head to replicate
> >> the credentials of the entire org to this small site.
> >>
> >>>
> >>>> 4)AD server maintained in the Data Center usually has better
> >>>> physical security than branch offices - what if someone breaks into
> >>>> the branch office and steals all the username + password ? (I am
> >>>> assuming the username, password are the same credentials used to
> >>>> access other critical enterprise resources)
> >>>
> > _______________________________________________
> > tram mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
> >
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Thu, 10 Apr 2014 08:58:35 -0400

I'm not sure this answers my question, so perhaps I was unclear.

What is the relationship between this corporate security policy and
discussion of hash agility? The only possible relevance that I can see
is the question of whether storing the hashed user:realm:passwd counts
as storing the credentials. With a good enough hash algorithm, I think
the answer is "no", and so the discussion of hash agility needs to
ensure that the algorithm is good enough.

If the credentials are not allowed to even be transmitted to the TURN
server, then the enterprise should treat the TURN server as a 3rd party
and use the 3rd party mechanism.

--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 11 Apr 2014 12:18:54 +0000

> Sent: Thursday, April 10, 2014 6:29 PM
> To: [email-masked]

I am only trying to say that Data at Rest in public cloud may have security implications compared to Data on transit and I see that other protocols that use first party authentication but do not have limitation of storing the credentials locally. 

-Tiru

> > Though 3rd party authorization does not have the problem of hash agility, I am
> not sure if that means first party authentication can be removed. TURN servers
> provided by Application servers may want to only use 3rd party authorization.
> But first party authentication may be required for Enterprise use cases. For
> example considering the requirement discussed in
> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-
> 14#section-3.3.5.1 where it is mandatory to for the Enterprise to use TURN for
> all external RTCWEB communication. The auditing policy requires TURN server
> should be aware of endpoints username/realm for logging purpose.
> >
> > If the Enterprise I.T decides to go with a cloud vendor either offering TURN
> servers or decides to setup it's TURN servers in a public cloud. The
> authentication mechanism requires that either the TURN server should know the
> user credentials or alternatively gets the credentials from the AD server
> deployed in the Enterprise Data Center. But both mechanisms may not
> acceptable since it requires the credentials to be stored outside the Enterprise
> premises. The  policy violations with the current authentication mechanism
> would be that:
> >
> > * Data is extremely sensitive and the management cannot risk hosting it on
> public infrastructure but at the same time wants to leverage cloud services
> >>>>>> company) where NNN number of new users join, MMM users leave
> every
> >>>> day.