Subject: Re: Theoretical SLP security discussion (long)

From: James Kempf <[email-masked]>
Date: Mon, 22 Jan 2001 14:30:48 -0800 (PST)

>> SLP authentication is for authenticating the service advertisement, not
>> the service. The service needs to perform its own authentication.
>>
>
>Two things:
>
>1) Doesn't authentication of the service advertisement imply service
>authenticity?  If I'm wrong, please offer an example of when a trusted
>service registration can exist for an un-trusted service (or visa
>versa).
>

Technically, the UA is authenticating the supplier of the service
location information, while the service is authenticating the user.
It's only the same if you believe the trust relationship is automatically
bidirectional. i.e., the fact that the user has the information means that they 
can be trusted. This is, in general, not a good policy, though it might
work in some looser trust situations. For example, I might see the
URL on your whiteboard and use it, even though I'm not authorized.

>2) If the service needs to perform its own authentication, then *why*
>does the service registration need to be authenticated at all?  The only
>reason to really need authentication in SLPv2 is if the services being
>advertised have now way to communicate their authenticity other than via
>SLP.  Other than obvious "denial of service"-type problems (mentioned in
>this thread by Ebenezer Schubert <[email-masked]>), are there any other
>problems that would result from malicious, or otherwise untrustworthy
>SLP advertisements?
>

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.

>>
>> You are right that key distribution is currently an issue, but that is
>> not just for SLP, it is for any network service that wants to use
>> key-based security.
>>
>
>Agreed.  Do you have any suggestions as to how to proceeded with
>implementation of SLPv2 authentication when standards in this area are
>so flaky?  
>

I'n not a security person, so I can't really make any recommendations.

>In the absence of a standard, I'm wondering if modification to the SLP
>API might be in order.  Allowing developers to feed the SLP
>implementations authentication information would make it possible for
>developers to use proprietary or emerging standards for key/certificate
>distribution.  With the current API, there is no way to use diverse
>key/certificate distribution methods without writing a custom SLP
>implementation.  
>
>I have been thinking of a minor (backwards compatible) change to
>SLPOpen() that would allow encapsulation of authentication information
>in the SLPHandle.  I need some more time to hammer out the details. 
>I'll post the proposal in another thread.
>

I'm certainly open to seeing what you have in mind, but, in general, we
were trying to avoid putting anything in the API for security (with
the exception of error codes) because we wanted security be strictly
a configuration issue, either dynamic via a PKI or static. As you state,
with the current situation, it is not possible to configure security
easily, but I don't think this should be fixed on an API by API basis.
You will note that there is a property for turning security on, and
we could consider a property for installing a key, certificate, or SPI,
but I don't think it would be such a good idea to explicitly put this
into the API itself.

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

---

From: Matt Peterson <[email-masked]>
Date: Mon, 22 Jan 2001 17:47:49 -0700

[... previous thread posts snipped ...]

> URL on your whiteboard and use it, even though I'm not authorized.

Then we agree right?  What you are saying is that SLP does imply service
authenticity.  What I mean is... as a client application, "I trust that
SLP Service URLs are the services they say they are because SLP said
so".  In other words, if I ask for a POP3 service type, I only get
Service URLs of trusted POP3 services.  This is important because (in
absence of a better POP3 specific mechanism) my SLP enabled POP3 client
will give away my username and password to a POP3 service based solely
on the trust established by SLP mechanisms that located the POP3
service.

What I'm questioning is whether SLP should be expected to fill this role
of service (not client) authenticator.  

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.

> believe that the user is authenticated by virtue of their having your

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.

> but I don't think it would be such a good idea to explicitly put this

OK, I'll see if I can get a minute to write something...

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

---

From: Erik Guttman <[email-masked]>
Date: Sat, 27 Jan 2001 16:02:09 +0100

> client and the authenticity of the client to the service.  

In practice these features are hardly ever used.  Very few client
side certificates are used with SSH or SSL to authenticate the
client to the server.

> As you

To clarify, SLP security is used for two things.  

First, to make it difficult to set up a 'rogue DA' which hides genuine 
advertisements from UAs.  UAs which are configured with a SLP SPI to 
apply to DAAdverts will not use DAs which can't be authenticated.  This 
eliminates a trivial way to subvert SLP.  

Second, SAs which are set up to do so can add digital signatures to
their 
service advertisements.  UAs and DAs verify these advertisements before
accepting them.  This has the effect of informing the end user (through
the UA) that the SA was set up with keying material.  In other words,
site 
administration believes users (via SLP UAs) can trust information SLP
gives 
them about those services which are authenticated.

Most services do not authenticate themselves to clients (NFS, IMAP,
SMTP,
LP, SYSLOG, etc do not.  Even services over SSL don't.  Users are simply
provided with a certificate which they can manually verify, if they know
enough to do so).  SLP authentication, while far from being a complete
pixie dust solution, would provide a lot more security to service
location
than exists today.

Note however SLP authentication doesn't authenticate the actual client-
server interaction.  This could be subverted any number of ways and 
requires its own security mechanisms.

Erik