Subject: Re: Theoretical SLP security discussion (long)

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

Matt,

SLP authentication is for authenticating the service advertisement, not
the service. The service needs to perform its own authentication.

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. 

		jak
		
>X-Authentication-Warning: wicked.neato.org: majordom set sender to 
[email-masked] using -f
>Date: Fri, 19 Jan 2001 16:59:32 -0700
>From: Matt Peterson <[email-masked]>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: [email-masked]
>Subject: Theoretical SLP security discussion (long)
>Content-Transfer-Encoding: 7bit
>
>Greetings,
>
>The following is a summary of an SLP security discussion that took place
>a few weeks ago at Caldera Systems.  The discussion eventually boiled
>down to a fundimental question of whether service authentication be
>performed via SLP or via a different (possibly security specific)
>mechanism. 
>
>SLPv2 is designed to be able to authenticate agents.  In other words,
>SLPV2 can guarantee that SAs and DAs are trustworthy.  With a proper
>SLPv2 implementation and installation, UAs can be sure that replies to
>SLP requests come from trustworthy agents.  There is no need to wonder
>if responding agent is representing malicious services.  For example,
>with SLPv2 authentication, I can request a service of type
>"service:ldap" and implicitly trust that the service urls I receive in
>return are ldap servers that are considered trustworthy by whoever set
>up the SLP installations.
>
>Sounds pretty nice doesn't it -- at least until you start thinking about
>what is required to deliver key information (certificates) that makes
>trust relationships possible.  I think I'm safe in saying that without
>exception, no automated delivery of key information is secure unless it
>requires actual validation by a human that results in some form of
>real-life action (phone call, hand delivery, etc).  
>
>Administration of trust relationships are completely un-addressed by the
>SLPv2 and SLP API specs -- which is probably why authentication is
>considered an optional feature.  One might even take the position that
>SLPv2 Authentication invalidates the SLP's claim to reduce
>administrative workload as there is no way to deploy secure SLP without
>significant (manual) administrative overhead to establish certificate or
>key information trust.
>
>In contemplating implementation and use of SLPv2 authentication in
>OpenSLP we found that there is nearly nothing in the way of standardized
>certificate delivery mechanisms that might actually make SLPv2
>authentication possible.   We did find bits and pieces from OpenSSL and
>various signing utilities, which lead us to start questioning why we
>were trying to authenticate services via SLP anyway?  Why not just let
>services authenticate themselves?
>
>An analogy from real life...  I need to call an associate and relay some
>confidential information.  I write down his number as it was left on my
>voice mail and place the phone call.  BEFORE I exchange sensitive
>information the individual on the other line, I authenticate their
>identity (recognize their voice, etc).  Trusting the information
>available on my voice mail is not required (as the number may have be to
>an airport pay phone).   Implicitly trusting a phone number from the
>white pages or any other source is not required (or expected) as long as
>the callers can authenticate themselves.
>
>Likewise, SLP delivered information need not be trusted to be useful. 
>As long as the entity providing a service and the entity using the
>service can authenticate each other -- separate from the mechanism used
>to discover or locate one another.  One problem is that many services do
>not have authentication capabilities -- which is not too much of a
>problem because most services don't have SLP capabilities either.  In
>the end, the only problem is that developers are just beginning to write
>secure software.  If secure service and client software were indeed
>available, there would not be any need for SLP authentication.
>
>Having not heard additional comment from other experts, it is my opinion
>the SLP need not bear the burden of authenticating services.  The burden
>of authentication should be placed on the services and their clients
>rather than on a protocol valued for simplicity and ease of use,
>administration, and deployment.  
>
>Please comment.  Do you agree or disagree?  Why? 
>
>--
>Matthew Peterson
>Sr. Software Engineer
>Caldera Systems, Inc
>[email-masked]

---

From: Matt Peterson <[email-masked]>
Date: Mon, 22 Jan 2001 14:31:42 -0700

> 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).

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?

> not just for SLP, it is for any network service that wants to use

Agreed.  Do you have any suggestions as to how to proceeded with
implementation of SLPv2 authentication when standards in this area are
so flaky?  

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.

Regards,

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