Subject: Re: [tram] STUN hash agility

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 7 Apr 2014 18:33:00 +0000

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

> -----Original Message-----
> 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
> 
> > -----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: Brandon Williams <[email-masked]>
Date: Mon, 07 Apr 2014 15:10:59 -0400

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?

--Brandon

On 04/07/2014 02:33 PM, Tirumaleswar Reddy (tireddy) wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

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