Subject: Re: Theoretical SLP security discussion (long)

From: James Kempf <[email-masked]>
Date: Tue, 23 Jan 2001 17:26:37 -0800 (PST)

>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: James Kempf <[email-masked]>
Date: Wed, 24 Jan 2001 09:34:25 -0800 (PST)

Matt,

Your arguments are valid, but I beleive the general feeling at the IETF
is that you can "sort of" trust DNS and you can absolutely trust routers.
The "sort of" becomes "absolutely" if you deploy secure DNS. As for routers,
I don't know routing protocols enough to say whether there is any security
in them, thus whether the "absolutely" is justified.

With regard to security v.s. ease of configuration, this issue has come
up a number of times in the zeroconf working group, and they are looking
at solutions. There are some possibilities, especially for small devices,
but all involve the user, who may be a consumer with no expertise or
interest in having to deal with systems administration, performing some
action on the device to configure it when it gets installed. For example,
the serial number could be used as a private key, and the consumer would
need to do something simple to cause a public key to get generated and 
distributed. Stuff like that. 

With regard to SLP security, if you have some simple procedure available
to initialize security, then it becomes less of a burden to use. Of
course, there needs to be infrastructure in place to support it. In that
sense, the SLP security design was meant to be forward looking, to a
time, hopefully in the not too distant future, when the security infrastructure
is in place to support it and simple procedures for configuring security,
that leverage off the infrastructure, are well understood.

For now, as you point out, turning on security in SLP results in a major
loss in the attractiveness of lighweight configuration, and therefore
is somewhat of a disincentive.

		jak

>Date: Wed, 24 Jan 2001 10:14:52 -0700
>From: Matt Peterson <[email-masked]>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: "McDonald, Ira" <[email-masked]>
>CC: "'James Kempf'" <[email-masked]>, [email-masked]
>Subject: Re: Theoretical SLP security discussion (long)
>Content-Transfer-Encoding: 7bit
>
>Ira and Jak,
>
>"McDonald, Ira" wrote:
>> 
>> 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)
>> 
>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]

---

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 26 Jan 2001 14:02:38 -0800

Hi Matt,

I agree with your conclusion (that the use of SLPv2
authentication is NOT appropriate to actually
authenticate an advertising service to a client or
vice versa).

And I agree that SLP is a _good thing_ in the plug
and play environment (i.e., IETF Zero Config WG).

Cheers,

-----Original Message-----
From: Matt Peterson [mailto:[email-masked]]
Sent: Wednesday, January 24, 2001 9:15 AM
To: McDonald, Ira
Cc: 'James Kempf'; [email-masked]
Subject: Re: Theoretical SLP security discussion (long)

Ira and Jak,

Exactly!

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