which security protocol for dealing with this situation

which security protocol would enable two particular computers to
connect and autenticate that each other are talking to the machine
they're supposed to be?

actual situation:

piece of software running on base machine which is connected to the
net via broadband (so dynamic ip address), so it has subscribed to a
dynamic ip address service like www.dyndns.org.

mobile device with internet capability wants to connect to base
machine so uses the dyndns address. at this point the base machine
should request a password, and the mobile device user provides the
password, but something's needed to cope with a possible man in the
middle attack. assuming someone has remapped the ip address of the
base machine to themselves how can that be dealt with? which protocol,
if there is one, will do this? the base machine and mobile device can
share a secret reliably in the set up stage and possibly/probably at
later stages (because the mobile device owner and the base machine
owner are one in the same and can physically connect the two when
setting it up).

any ideas? thanks.

Re: which security protocol for dealing with this situation

You're looking for machine-to-machine security. This means that no users
should be involved -- there should be no waiting or prompting humans for
passwords.

IPsec is exactly what you need. In your policies, you can specify DNS names
rather than IP addresses, so I don't see an issue with DynDNS.

Are these Windows computers?


Steve Riley
steve.riley@microsoft.com
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com


wrote in message
news:1190925917.297788.26430@g4g2000hsf.googlegroups.com...
> which security protocol would enable two particular computers to
> connect and autenticate that each other are talking to the machine
> they're supposed to be?
>
> actual situation:
>
> piece of software running on base machine which is connected to the
> net via broadband (so dynamic ip address), so it has subscribed to a
> dynamic ip address service like www.dyndns.org.
>
> mobile device with internet capability wants to connect to base
> machine so uses the dyndns address. at this point the base machine
> should request a password, and the mobile device user provides the
> password, but something's needed to cope with a possible man in the
> middle attack. assuming someone has remapped the ip address of the
> base machine to themselves how can that be dealt with? which protocol,
> if there is one, will do this? the base machine and mobile device can
> share a secret reliably in the set up stage and possibly/probably at
> later stages (because the mobile device owner and the base machine
> owner are one in the same and can physically connect the two when
> setting it up).
>
> any ideas? thanks.
>

Re: which security protocol for dealing with this situation

ben@mailinator.com writes:

> which security protocol would enable two particular computers to
> connect and autenticate that each other are talking to the machine
> they're supposed to be?

ssh would provide for these requirements. The ssh server has a host
key that a proper ssh client will ask to verify upon initial
connection, and will store for later conenctions, warning you if
the host key changes.


To do the initial verification, the client can call or email a trusted
party asking for the output of

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
$ ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub

and making sure one of those fingerprints matches what the client is
seeing.

If the "base" machine is not running a linux variant, the ssh server
you use will have some sort of analogous way of giving a fingerprint
of the server's host key.




> actual situation:
>
> piece of software running on base machine which is connected to the
> net via broadband (so dynamic ip address), so it has subscribed to a
> dynamic ip address service like www.dyndns.org.
>
> mobile device with internet capability wants to connect to base
> machine so uses the dyndns address. at this point the base machine
> should request a password, and the mobile device user provides the
> password, but something's needed to cope with a possible man in the
> middle attack. assuming someone has remapped the ip address of the
> base machine to themselves how can that be dealt with? which protocol,
> if there is one, will do this? the base machine and mobile device can
> share a secret reliably in the set up stage and possibly/probably at
> later stages (because the mobile device owner and the base machine
> owner are one in the same and can physically connect the two when
> setting it up).
>
> any ideas? thanks.
>

--
Todd H.
http://www.toddh.net/

Re: which security protocol for dealing with this situation

thanks for the reply.

On Sep 27, 9:58 pm, "Steve Riley [MSFT]"
wrote:
> You're looking for machine-to-machine security.

I suppose so yes.

> This means that no users
> should be involved -- there should be no waiting or prompting humans for
> passwords.

Well if that's possible, good. Makes it easier to use.

> IPsec is exactly what you need.

Right. Just read a bit about that. It's part of IPv4 (optionally) &
IPv6 (not optionally) right? Is that what you mean by IPsec?

> In your policies, you can specify DNS names
> rather than IP addresses, so I don't see an issue with DynDNS.

Well a machine making itself available on the net via the www.dyndns.org
service needs to run a utility which says to dyndns.org "my ip address
has changed to ...", so it's standard practice for machines to
initiate a change in their dns mapping -- I can imagine that being
tamperable with -- a vulnerablility. Someone could send out a false '
"my" ip address has changed' message. So, assuming that that's quite
possible, I was thinking there should be some authentication between
the real base machine and the mobile user to make sure each other are
the right things without a man in the middle getting the
authentication info/password or whatever thus being able to access the
base machine themselves.

> Are these Windows computers?

It's a fairly hyperthetical situation at the moment -- I'm designing a
piece of software which I intend to write. I'm intending making it
cross platform: Windows, Unix inc. Mac and Linux. The mobile device at
the moment in my mind is not Windows or anything like that, it just
has a web browser, but, by the time I've written this software mobile
phones will probably have developed somewhat so installing a utility/
app written for this will be much more feasible. Let's assume we're
talking about a mobile device which has a web browser with JavaScript
etc. and that's how the commincation will take place. Possible? If
with web browser not possible then assume specifically written utility/
app for mobile device is possible.

Thanks, Ben.

Re: which security protocol for dealing with this situation

On Sep 27, 10:48 pm, comph...@toddh.net (Todd H.) wrote:

> ssh would provide for these requirements. The ssh server has a host
> key that a proper ssh client will ask to verify upon initial
> connection, and will store for later conenctions, warning you if
> the host key changes.

Hmm, I was recently looking into a ssh connection for a shopping cart
web site as ssh was essential for that if taking credit card numbers
directly. Didn't do it in the end but for that it seemed a 3rd party
certificate server was needed at a subscription cost per year. And the
IP address of the merchant's server had to be static. But I've just
read about ssh in a security book which I'm reading at the moment
(Computer Security 2ed Dieter Gollman) and what was in that book
didn't really tally with what I found out when I was looking into
implementing a shopping cart web site -- in particular the 3rd party
certificate server part wasn't mentioned at all in the book for ssh I
don't think, so I'm not sure what's going on there entirely.

Forgetting online store web servers, for what I'm asking about would a
3rd party certificate server therefore subscription be necessary?
Would like to avoid anything like that if possible.

> To do the initial verification, the client can call or email a trusted
> party asking for the output of
>
> $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
> $ ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub
>
> and making sure one of those fingerprints matches what the client is
> seeing.
>
> If the "base" machine is not running a linux variant, the ssh server
> you use will have some sort of analogous way of giving a fingerprint
> of the server's host key.

OK, thanks.

Re: which security protocol for dealing with this situation

IPsec is an optional part of most IPv4 implementations. It's been in Windows
since Windows 2000. You can get IPsec for all modern stacks these days. And
yes, it's mandatory in IPv6.

The cool thing about IPsec is that the policies really aren't spoofable or
even movable. So let's say that on your legitimate server, today it gets the
IP address 1.2.3.4 from your ISP. So it updates DynDNS, saying, "Hello, I'm
Ben's foobar server. Today my IP address is 1.2.3.4." Fine and dandy. You'll
have an IPsec policy on your server that says, "Incoming connection from
mobile device requires IPsec. The policy must use preshared
key ."

You will also have an IPsec policy on the mobile device that says, "Outgoing
connection from me to Ben's-foobar-server requires IPsec. Use preshared key
."

Now, to address your concern of spoofed DynDNS updates. If an attacker were
to tell DynDNS that he is you (and I really don't know whether this is even
possible), the IPsec requirement prevents your mobile device from connecting
to your server. It would be very unlikely that the attacker would know the
pre-shared key you've configured, especially if you use a sentence. And the
attacker can't discover the key: it's never sent over the air, but rather is
used as part of a six-step authentication process.

IPsec has been around for a long time and is designed for many scenarios,
including the one you're describing.


Hmm . . . I just read your reply again. You say the mobile device isn't a
laptop, but a phone? Wow. I don't know of any phone OS that includes IPsec
just yet. So maybe I'll change my recommendation. You do indicate that the
app on the mobile device is a browser -- so I'm assuming that the server is
running a web app. Now I'm thinking that SSL/TLS is your best choice. You'd
enroll your server for a certificate from one of the public certificate
authorities (VeriSign is always popular), and when you do, use the same name
as the name you're using for the server at DynDNS. This works fine because
certificates don't care about IP addresses. Then in the app on the phone,
simply require that the phone make a successful SSL/TLS connection to your
sever. Your server presents its certificate, and then a secure channel is
established between the phone and the server.

Again, this protects you from your worry. If an attacker tries to take over
your DynDNS registration, his server won't have your certificate, so your
phones won't connect.

Steve Riley
steve.riley@microsoft.com
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com



wrote in message
news:1190929971.627652.226240@n39g2000hsh.googlegroups.com.. .
> thanks for the reply.
>
> On Sep 27, 9:58 pm, "Steve Riley [MSFT]"
> wrote:
>> You're looking for machine-to-machine security.
>
> I suppose so yes.
>
>> This means that no users
>> should be involved -- there should be no waiting or prompting humans for
>> passwords.
>
> Well if that's possible, good. Makes it easier to use.
>
>> IPsec is exactly what you need.
>
> Right. Just read a bit about that. It's part of IPv4 (optionally) &
> IPv6 (not optionally) right? Is that what you mean by IPsec?
>
>> In your policies, you can specify DNS names
>> rather than IP addresses, so I don't see an issue with DynDNS.
>
> Well a machine making itself available on the net via the www.dyndns.org
> service needs to run a utility which says to dyndns.org "my ip address
> has changed to ...", so it's standard practice for machines to
> initiate a change in their dns mapping -- I can imagine that being
> tamperable with -- a vulnerablility. Someone could send out a false '
> "my" ip address has changed' message. So, assuming that that's quite
> possible, I was thinking there should be some authentication between
> the real base machine and the mobile user to make sure each other are
> the right things without a man in the middle getting the
> authentication info/password or whatever thus being able to access the
> base machine themselves.
>
>> Are these Windows computers?
>
> It's a fairly hyperthetical situation at the moment -- I'm designing a
> piece of software which I intend to write. I'm intending making it
> cross platform: Windows, Unix inc. Mac and Linux. The mobile device at
> the moment in my mind is not Windows or anything like that, it just
> has a web browser, but, by the time I've written this software mobile
> phones will probably have developed somewhat so installing a utility/
> app written for this will be much more feasible. Let's assume we're
> talking about a mobile device which has a web browser with JavaScript
> etc. and that's how the commincation will take place. Possible? If
> with web browser not possible then assume specifically written utility/
> app for mobile device is possible.
>
> Thanks, Ben.
>
>

Re: which security protocol for dealing with this situation

On Sep 27, 11:39 pm, comph...@toddh.net (Todd H.) wrote:

> An SSL certificate on the "base" computer's web server would provide
> this verification that you're talking to the compute ryou think you
> are.
>
> And DynDNS sells them:
> http://www.dyndns.com/services/sslcert/
>
> The "real" server assumably would be the only one running the web
> server with the SSL certificate issued to whatever.dyndns.org
>
> So long as hasty users don't click through any warning boxes about
> mismatching certificates, and so long as a certificate authority
> trusted by the web browser in question doesn't issue a bad guy a
> certificate for someone else' dyndns domain, I think you're where you
> wanna be.

Yes that looks like, without entirely knowing/understanding the
details, exactly what I'm after... apart from the $139 per year bit.
Tis a great shame that's necessary. Is there possibly another way that
doesn't require subscription? I suppose the good thing about ssl is
that browsers support it. What if installing custom utility/app on
phone was possible?; What other methods would then be possible? PGP?
Would that be useful? What about what Steve Riley was talking about
above, IPsec?

Bearing in mind the phone and base machine can be synchronised/aligned
with each other securely/safely beforehand, and intermittently during
the course of use, does that allow for some protocol to be used which
doesn't require these third parties possibly?

Thanks.

Re: which security protocol for dealing with this situation

ben@mailinator.com writes:
> It's a fairly hyperthetical situation at the moment -- I'm designing a
> piece of software which I intend to write. I'm intending making it
> cross platform: Windows, Unix inc. Mac and Linux. The mobile device at
> the moment in my mind is not Windows or anything like that, it just
> has a web browser, but, by the time I've written this software mobile
> phones will probably have developed somewhat so installing a utility/
> app written for this will be much more feasible. Let's assume we're
> talking about a mobile device which has a web browser with JavaScript
> etc. and that's how the commincation will take place. Possible? If
> with web browser not possible then assume specifically written utility/
> app for mobile device is possible.


An SSL certificate on the "base" computer's web server would provide
this verification that you're talking to the compute ryou think you
are.

And DynDNS sells them:
http://www.dyndns.com/services/sslcert/


The "real" server assumably would be the only one running the web
server with the SSL certificate issued to whatever.dyndns.org

So long as hasty users don't click through any warning boxes about
mismatching certificates, and so long as a certificate authority
trusted by the web browser in question doesn't issue a bad guy a
certificate for someone else' dyndns domain, I think you're where you
wanna be.


--
Todd H.
http://www.toddh.net/

Re: which security protocol for dealing with this situation

ben@mailinator.com writes:

> On Sep 27, 10:48 pm, comph...@toddh.net (Todd H.) wrote:
>
> > ssh would provide for these requirements. The ssh server has a host
> > key that a proper ssh client will ask to verify upon initial
> > connection, and will store for later conenctions, warning you if
> > the host key changes.
>
> Hmm, I was recently looking into a ssh connection for a shopping cart
> web site as ssh was essential for that if taking credit card numbers
> directly. Didn't do it in the end but for that it seemed a 3rd party
> certificate server was needed at a subscription cost per year.


Is it possible you're confusing SSL (secure sockets layer, synonymous
colloquially with https:// and securing website traffic in transit)
and ssh (secure shell)


> And the IP address of the merchant's server had to be static. But
> I've just read about ssh in a security book which I'm reading at the
> moment (Computer Security 2ed Dieter Gollman) and what was in that
> book didn't really tally with what I found out when I was looking
> into implementing a shopping cart web site -- in particular the 3rd
> party certificate server part wasn't mentioned at all in the book
> for ssh I don't think, so I'm not sure what's going on there
> entirely.


SSH doesn't use third party certificates, certificate authorities or
what not. ssh-keygen creates its own key and the whole sticky wicket
of verification is left up to the individual user. No trusted cert
authorities are employed.

However, given requirements that you illuminated in another post
(i.e. you can't install any software on your clients), SSH ceases to
be a usable solution. To use SSH, you'd need an SSH enabled client
program.

> Forgetting online store web servers, for what I'm asking about would
> a 3rd party certificate server therefore subscription be necessary?

It depends.

> Would like to avoid anything like that if possible.

Okay, if your clients only have web browsers available, and if you
dont' want base computer owners to pay any sort of certificate fee,
your best option is probably going to be creating self signed SSL
certificates, but... the verification of whether the client trusts to
connect to the server will be handled by the web browser in the mobile
device, not anything under your control.

So, to be really sure, a diligent user would have to scrutinize the
self signed certificate (and the web browser should prompt the user
with a warning when it encounters SSL certificates that aren't signed
by a certificate authority the browser trusts), and the user could
contact the base computer owner independently to verify its
authenticity. But such diligent users are quite an exception.


There may be other ideas out there. I'm not a crypto and certificate
expert by any stretch.

Best Regards,
--
Todd H.
http://www.toddh.net/

Re: which security protocol for dealing with this situation

On Sep 27, 11:48 pm, comph...@toddh.net (Todd H.) wrote:
> b...@mailinator.com writes:
> > On Sep 27, 10:48 pm, comph...@toddh.net (Todd H.) wrote:
>
> > Hmm, I was recently looking into a ssh connection for a shopping cart
> > web site as ssh was essential for that if taking credit card numbers
> > directly. Didn't do it in the end but for that it seemed a 3rd party
> > certificate server was needed at a subscription cost per year.
>
> Is it possible you're confusing SSL (secure sockets layer, synonymous
> colloquially with https:// and securing website traffic in transit)
> and ssh (secure shell)
>
> > And the IP address of the merchant's server had to be static. But
> > I've just read about ssh in a security book which I'm reading at the
> > moment (Computer Security 2ed Dieter Gollman) and what was in that
> > book didn't really tally with what I found out when I was looking
> > into implementing a shopping cart web site -- in particular the 3rd
> > party certificate server part wasn't mentioned at all in the book
> > for ssh I don't think, so I'm not sure what's going on there
> > entirely.
>
> SSH doesn't use third party certificates, certificate authorities or
> what not. ssh-keygen creates its own key and the whole sticky wicket
> of verification is left up to the individual user. No trusted cert
> authorities are employed.

Ah, yes, I have been getting confused between ssh and ssl in this
thread, but not previously; ssh didn't figure previously. It's SSL/TLS
(which goes between the application and TCP layer in the internet
protocol stack) in the book, and it's SSL (as you say https://) which
you need for an online store -- so same thing in both those cases.


Thanks to both of you for your answers. Too late for me to digest all
this now. Will do tomorrow, and will probably have more questions.

Thanks. Ben.

Re: which security protocol for dealing with this situation

ben@mailinator.com writes:

> Thanks to both of you for your answers. Too late for me to digest all
> this now. Will do tomorrow, and will probably have more questions.

No problem. If you endeavor to implement this, there are lots of way
to do it wrong, which are covered with explicit coding examples in
this book:

http://www.amazon.com/Deadly-Sins-Software-Security-One-off/ dp/0072260858

But I'm sure there are others that focus just on SSL implementation.

--
Todd H.
http://www.toddh.net/