authentication (SRP*, DH, TLS)

Introduction:
I'm working on a commercial product which was ported from
win32 to GNU/Linux. While doing so we have used TCP/IP
sockets instead of Named Pipes for IPC. By doing so
we've lost the big advantage of having DACLs set on the
named pipes that prevent unauthorized access to the
services.
Now I'm trying to recreate that with the tcp sockets version.
Because of the performance hit we can't use TLS which
checks client+server certificates for preventing MITM.

After evaluating the possibilities I've come to the conclusion
that SRP-6 could be a possible solution.

What I'm trying to find out is:
* is SRP-6 really MITM proof
* how do I prevent using SRP-Z mode which requires royalties
* are there any better implementations than Tom Wu's default
one which when fed to modern compilers like VC8 requires
too much massaging to be compilable and warning-free. I've
not even tried gcc-4.x yet.
* is it legal to use libsrp with the embedded 1996 copy of
getopt.[c,h] which says it is licensed
"GNU Library General Public License" under. actually I'm
not sure (I'll assume this is LGPL) this is legal as LGPL
defines linking against the lib only AFAIK

* what other options do I have to implement secure
authentication (secret not visible on wire) without encrypting
the channel

PS: I may cross-post this initial message in same/similar form
to other groups/lists to get broad feedback. sorry if this
list/group was not the right place to ask (I tried to select
the right lists/groups).

Re: authentication (SRP*, DH, TLS)

gmu2006@gmail.com writes:

> Introduction:
> I'm working on a commercial product which was ported from
> win32 to GNU/Linux. While doing so we have used TCP/IP
> sockets instead of Named Pipes for IPC. By doing so
> we've lost the big advantage of having DACLs set on the
> named pipes that prevent unauthorized access to the
> services.

If you use Unix domain sockets instead of TCP/IP, you can use standard
filesystem permissions to protect them.

Not sure about SRP6. :)

----Scott.

Re: authentication (SRP*, DH, TLS)

it's not manchine-local only, it's also used network-wide.

Re: authentication (SRP*, DH, TLS)

it's not manchine-local only, it's also used network-wide.

Re: authentication (SRP*, DH, TLS)

it's not manchine-local only, it's also used network-wide.

Re: authentication (SRP*, DH, TLS)

I'm really sorry, didn't know google groups does the multi-post.

Re: authentication (SRP*, DH, TLS)

gmu2006@gmail.com wrote:
> it's not manchine-local only, it's also used network-wide.

The confusion probably comes from the fact that on Windows (with
NetBIOS), named pipes are a network IPC mechanism, whereas on
Unix, there is also something called named pipes, but it is a
different mechanism and it only works within one machine (the
namespace for the pipes is the local filesystem).

You didn't state it, but when you said you used TCP instead of
named pipes, you probably meant you replaced the existing Windows
named pipes with TCP when porting rather than choosing TCP over
Unix named pipes when evaluating the choices for IPC on Unix
(which is what I thought you meant at first).

- Logan

Re: authentication (SRP*, DH, TLS)

gmu2006@gmail.com wrote:
>
> it's not manchine-local only, it's also used network-wide.

Not only have you repeated this, but it is totally incomprehensible
and useless. What is 'it', etc. Include context. Google is NOT
usenet, it is only a poor broken interface to usenet. There is
never any guarantee that any other message is visible to your
reader, so your article has to stand by itself. For means of doing
this on the foul google interface, see below.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at:
Also see

Re: authentication (SRP*, DH, TLS)

In comp.security.misc gmu2006@gmail.com wrote:
> I'm working on a commercial product which was ported from
> win32 to GNU/Linux. While doing so we have used TCP/IP
> sockets instead of Named Pipes for IPC. By doing so
> we've lost the big advantage of having DACLs set on the
> named pipes that prevent unauthorized access to the
> services.

Yes. In a *NIX environment, the network service has to implement its
own security system.

> Now I'm trying to recreate that with the tcp sockets version.
> Because of the performance hit we can't use TLS which
> checks client+server certificates for preventing MITM.

This is a completely other topic. For preventing MITM attacks,
implementing authentication is not enough, neither with ACLs on named
pipes, nor with authentication implemented for network services using
TCP sockets.

> * is it legal to use libsrp with the embedded 1996 copy of
> getopt.[c,h] which says it is licensed
> "GNU Library General Public License" under.

Yes. LGPL means, you may link to and you may keep your own code closed
source and proprietary.

> * what other options do I have to implement secure
> authentication (secret not visible on wire) without encrypting
> the channel

Use public key cryptography for key exchange:

http://en.wikipedia.org/wiki/Public-key_cryptography
http://en.wikipedia.org/wiki/Password-authenticated_key_agre ement
http://en.wikipedia.org/wiki/Encrypted_key_exchange

Or use RSA or DSA:

http://en.wikipedia.org/wiki/RSA
http://en.wikipedia.org/wiki/Digital_Signature_Algorithm

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: authentication (SRP*, DH, TLS)

CBFalconer wrote:
> gmu2006@gmail.com wrote:
> >
> > it's not manchine-local only, it's also used network-wide.
>
> Not only have you repeated this, but it is totally incomprehensible
> and useless. What is 'it', etc. Include context. Google is NOT
> usenet, it is only a poor broken interface to usenet. There is
> never any guarantee that any other message is visible to your
> reader, so your article has to stand by itself. For means of doing
> this on the foul google interface, see below.

first of all thanks for the reply hint. moreover I will only use
comp.programming
instead of cross-posting. sorry for the SPAM.

now to what I mis-wrote: yes the IPC is used between real hosts via
network.
'it' is IPC.

Re: authentication (SRP*, DH, TLS)

Scott W Gifford writes:

>gmu2006@gmail.com writes:

>> Introduction:
>> I'm working on a commercial product which was ported from
>> win32 to GNU/Linux. While doing so we have used TCP/IP
>> sockets instead of Named Pipes for IPC. By doing so
>> we've lost the big advantage of having DACLs set on the
>> named pipes that prevent unauthorized access to the
>> services.

>If you use Unix domain sockets instead of TCP/IP, you can use standard
>filesystem permissions to protect them.

No, you cannot depend on file permissions to protect Unix domain
sockets, not unless you use the file permissions to protect the
directory in which the socket resides. Some implementations allow
for permissions on sockets, but they cannot be relied upon.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Re: authentication (SRP*, DH, TLS)

On 15 Apr 2006 12:59:33 +0200, Volker Birk wrote:
> In comp.security.misc gmu2006@gmail.com wrote:
....
>> * is it legal to use libsrp with the embedded 1996 copy of
>> getopt.[c,h] which says it is licensed
>> "GNU Library General Public License" under.
>
> Yes. LGPL means, you may link to and you may keep your own code closed
> source and proprietary.

[if I knew the proper group for this, I would have added a followup-to]

That is an oversimplification, I think. If I recall correctly, dynamic
linking is ok, while static linking is not.

Please look into this in more detail. Or perhaps the simplest thing is to
borrow a getopt implementation from one of the BSDs.

/Jorgen

--
// Jorgen Grahn \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!

Re: authentication (SRP*, DH, TLS)

Jorgen Grahn wrote:
> > Yes. LGPL means, you may link to and you may keep your own code closed
> > source and proprietary.
> [if I knew the proper group for this, I would have added a followup-to]
> That is an oversimplification, I think. If I recall correctly, dynamic
> linking is ok, while static linking is not.

This is not true. For details, please read LGPL section 5 and 6:

http://www.gnu.org/licenses/lgpl.html

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain