Subject: RE: Theoretical SLP security discussion (long)

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 23 Jan 2001 19:17:27 -0800

Hi James and Matt,

Umm - Secure DNS is not at all widely deployed, in my
experience.  The chance of getting a name resolved to
a wrong IP address seems pretty high on the face of it.

And as IDNs (Internationalized Domain Names) start to
be deployed (if the IETF IDN WG ever agrees on _how_),
the chance for spoofing radically increases, I think.

Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
  High North Inc

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 5:27 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: Theoretical SLP security discussion (long)

>To be secure (ala SSH and SSL), something must guarantee the
>authenticity of *both* endpoints -- the authenticity of service to the
>client and the authenticity of the client to the service.  As you
>mentioned, most services have mechanisms to authenticate the client. 
>What is missing is the authentication of the service (is the service
>trustworthy!).  From posts to this thread and direct emails, I believe
>that people expect SLP authentication to be the "pixie dust" that allows
>clients to establish the authenticity of the service in the absence of a
>more appropriate mechanism that is specific to the service itself.
>

Well, yes, in a manner of speaking.

>> 
>> Because it's two different kinds of authentication. For SLP, it's the
>> UA authenticating the service information, for the service, its the
>> service authenticating the user. Like I said, it only works if you
>> believe that the user is authenticated by virtue of their having your
>> address.
>>
>
>Are you advocating that the service be authenticated to the client by
>virtue of client having the service's address?  If so, then you are
>expecting SLP to authenticate the service because SLP is the mechanism
>that delivered the service's address to the client.
>

No, there is still the issue of whether DNS has securely resolved the
server's name to the right IP address. If someone has compromised DNS,
it is possible for there to be a breach. If the URL contains an IP address,
however, I don't think there is any way short of compromising the routing
tables.

		jak

---

From: Matt Peterson <[email-masked]>
Date: Wed, 24 Jan 2001 10:14:52 -0700

Ira and Jak,

> however, I don't think there is any way short of compromising the routing

Exactly!

It looks like there is some agreement then -- that the only way ensure
secure communication is to establish the identity of the endpoints
separate from intermediate layers or "helper" protocols DNS, DHCP, NIS
and even SLP.  This being the case, what is the advantage of putting
authentication into SLP over simply working real authentication into
existing and future service and client protocols and software?  

I argue that in general networking settings, there is not an advantage
to SLPv2 authentication -- especially if requirements for authentication
reduce (or even eliminate entirely) the attractive "plug and play"
features of SLP.  

I have yet to read an argument in this thread that suggests that SLP
authentication (in standard networking settings) offers additional
security enhancements over what could otherwise be achieved with
properly written secure SLP enabled software.  In other words, with out
SLP authentication, I can still write perfectly secure systems and
applications that use unsecured SLP for service location.

Other than "denial of service" type attacks (which can only be prevented
by fear), have I overlooked scenarios where the statement above does not
apply?

Again, please don't misunderstand my intentions.  I am not suggesting
removal of authentication from SLPv2 as it has value in specialized
cases.  However, for me in a standard networking environment it still
seems like SLP authentication is not as relevant in the quest for secure
network software operation as security enhancement to service specific
software.  This is an important distinction to make in determining
appropriate allocation of engineering resources.  I post to the list for
a sanity check. 

-- 
Matthew Peterson
Sr. Software Engineer
Caldera Systems, Inc
[email-masked]