Subject: Theoretical SLP security discussion (long)

From: Matt Peterson <[email-masked]>
Date: Fri, 19 Jan 2001 16:59:32 -0700

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: [email-masked]
Date: Fri, 19 Jan 2001 16:22:29 -0800

Hi,

	My take on this  would  be that it needs to be  implemented  and the
	people deploying it should have the option of enabling/disabling it.

	Because if this is not  implemented, I can see a potential denial of
	service  attack, where a rogue SA/DA, keeps on responding to all the
	discovers sent by the UA.  Even though the authentication might fail
	when the application  tries to  authenticate  using other means.  It
	can stop the UA from finding the correct  SA/DA, there by creating a
	denial of service attack.

	On the other hand managing keys does make the protocol heavy weight.
	The problem of effective  key  management  issue, needs to be solved
	for most other  protocols  (like DHCP) as well.  Until then, we need
	to be doing the key  management  manually or use what openSSL  uses,
	and  when  there  is an  optimum  key  management  solution,  we can
	integrate into that.

	just my thoughts.

--
Regards,
Ebi
==============================================================================
Ebenezer Schubert                        Phone (Off) : 408-447-7652
Hewlett-Packard                          email: [email-masked]
19410, Homestead Road,                          [email-masked] 
Cupertino, CA 95014
Mailstop 43LP
==============================================================================

---

From: gabriel montenegro <[email-masked]>
Date: Sat, 20 Jan 2001 03:57:53 +0100

> Please comment.  Do you agree or disagree?  Why?

Well, I see both security at the service endpoints themselves (provider and consumer)
and security at  SLP as complementary. If one thinks about this from the point of view
of the end-to-end argument, it is clear that the only way for services to obtain the
assurances they absolutely require is to not trust any other layer (including SLP),
but to do it themselves. Yes, the endpoints must do this. However, just as in the
e2e argument, intermediate entities in the system can help by, for example,
reducing the error rate on a link (by doing local retransmits), or by protecting
agains denial of service attacks (as ingress filtering in the internet, or as in SLP
in the case at hand).

So I'd say: use both if you can. As to how to imbue the services themselves with
the security pixie dust, that's where having a reusable protocol core with such
characteristics makes sense (as in BEEP, for example).

-gabriel
--
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
29, chemin du Vieux Chene         Email: [email-masked]
38240 Meylan, FRANCE              Mobile: +33 673 99 56 62
Office: +33 476 18 80 45 (sun internal: x38045)
Fax:    +33 476 18 88 88

---

From: Matt Peterson <[email-masked]>
Date: Mon, 22 Jan 2001 10:52:20 -0700

>         denial of service attack.

I do not believe that the "denial of service" attack scenario described
above is much of an issue.

I think that it is worth clarifying that receiving incorrect information
(service URLs of rogue services from rogue DA/SAs) is not a problem that
involves the "SLP UA portion" of a client application.  The problem you
describe above involves the portions of the client application that
*use* information delivered by SLP -- the "UA portion" is only in charge
of *getting* the information not using it.  In other words, the problem
you describe above is an SLP usage problem not an SLP problem.

Regardless of whether or not SLPv2 authentication is implemented and
configured, client applications must not expect that SLP guarantees
availability.  SLP could not possibly be expected to guarantee the state
of the network or the persistent state of the registered service. 
Suppose that a service registers with SLP just before a WAN outage.  At
least for a certain amount of time clients would experience the same
"denial of service" symptoms you describe above.  The real solution is
to encourage developers to use the entire list of service URLs.  If
usage (connection to or authentication to) one service fails, the client
application should try the next. 

Denial of service scenarios like the one you describe are impossible to
prevent.  The only protection against denial of service attacks is
fear.  Yes, security by fear. Remember, "SLP is intended to function
within networks under cooperative administrative control."  The above
mentioned attack would be easy to detect, track and resolve; which means
that it would not probably not be much of a problem in the environments
SLP is written to run in (how many rogue DHCP servers do you see on your
network).

In private network environments, the security problems that you need to
worry about are those that allow confidential data to be compromised
(especially if it can be done in ways can not be detected.)  Denial of
service attacks to not compromise data. 

The argument from my original post is that even if SLP authentication
was implemented and configured correctly with (magically) delivered
certificates, there would still be significant service specific security
risks that would be dangerous even in private networks.  Upon close
inspection SLP authentication appears to solve only those security
problems that are not overly relevant to private networks in the first
place.  (Please, if I'm wrong here, give me some examples...)
 
>         and  when  there  is an  optimum  key  management  solution,  we can

I agree fully that SLP without authentication is in the same realm
(security wise) as DHCP.   My question remains -- Is this really a
problem in private networks?  If so, why?  DHCP continues to be a widely
deployed and extremely useful technology.   One of the most useful
aspects of DHCP (and SLP) is that there is no need for extensive
configuration.  Add requirements for establishing trust (certificates,
keys, etc.) and the "plug and play" features of DHCP and SLP are gone.

As this is a "theoretical discussion" I might mention that security is
not free.  There is always a usability vs. security trade off.  I might
also mention that sometimes *lack of* security is a feature if the goal
is usability.  

Comments?

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

---

From: Matt Peterson <[email-masked]>
Date: Mon, 22 Jan 2001 11:07:54 -0700

> characteristics makes sense (as in BEEP, for example).

I agree that intermediate entities can help the overall security
framework of end-to-end communications.  You partially identify my
problem when you write "use both if you can".  It is the "if you can
part" that has me worried.  The problem I see is that SLP becomes
un-useful when its "plug and play" features are eliminated by
requirements for establishing trust and I don't see any way around it.

On the other hand, SLP ,like DHCP, remains very useful even without
authentication as long as service/client software is written to
establish appropriate end-to-end security.  As mentioned in a previous
post, when usability is the goal, sometimes lack of security is a
feature...  Does SLP fit this category?  I still think yes...

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

---

From: Ebenezer Schubert <[email-masked]>
Date: Mon, 22 Jan 2001 10:28:55 -0800 (PST)

Hi,

	I think, I picked up the wrong example.

	Let me give you  another  example.  If I have a  workstation  on the
	shared  lan where my  manager's  PC is also  there.  Some  companies
	restrict  root  access to  people on the main  network.  So I cannot
	sniff around to find password.  If there is no security in SLP, then
	I can  register  one of  the  test  machines,  which  would  be in a
	different  network  (for which I have the root access to) as the pop
	server.  Then I get the user name and password of my  manager's  pop
	account  (The same  thing can be done for a print  spooler or a file
	server).

	If you follow DHCP working group, there has been  discussions  about
	providing  authentication for DHCP also.  So leaving out security is
	not a  solution.  We can make  the  default  action  as one  without
	security (until we find a key management  protocol which allows plug
	and play), this will keep the SLP plug and play feature  intact.  On
	the other hand if the  person  deploying  it feels that his  network
	needs more security, then he can enable security.

-ebi

---

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

>         account  (The same  thing can be done for a print  spooler or a file

Again, Don't you think this is more an illustration of the weakness of
POP3 protocol and mail server/client software than it is of SLP?  I
would argue that POP3 needs the security boost -- after all it is in the
business of securing an end to end communication.  SLP is not designed
to solve the end-to-end authentication problem ... or is it?

On the other hand, you do allude to a very valid point -- that most
traditional and widely deployed "end-to-end" service specific protocols
and software are not capable of secure service authentication.  (It is
usually possible authenticate the user, but client software can rarely
authenticate the server which means that there is no establishment of
trust before sending client side user credentials.)  

Should SLP be tasked with solving this problem?  The answer is
definitely YES if it can be done without completely squashing major SLP
usability features ("plug and play" features).  I guess I just don't see
how this can be done.
 
>         needs more security, then he can enable security.

I was un-aware that DHCP was working on security.  Thank you for
mentioning this.  I am interested in taking a look at how they propose
to overcome the administrative overhead of establishing trust without
squashing DHCPs "plug and play" features.

Also, I am not advocating removal of SLPv2 security.  I believe that it
is valuable for those applications where trust can be established with
out a great deal of administrative overhead.  However, in conventional
(existing) network usage (LAN, etc) SLP we are having a hard time seeing
how trust can be established without invalidating the SLP usability
claims.  

As you suggest, maybe the solution is to allow the network administrator
to enable SLP security if they feel it is necessary and worth the pain
of certificate delivery and related configuration -- a tough call when
complete trust would (theoretically) require *per service* certificate
delivery to *all* SLP SAs and UAs.  

Anyway, assuming this is the solution, there are still serious
deficiencies in the SLP API that would make it difficult (if not
impossible) to take advantage of any kind of proprietary or standardized
authentication/trust framework...  I'll post separately on this subject
later.

Thank you for your comments.

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

---

From: Erik Guttman <[email-masked]>
Date: Fri, 26 Jan 2001 07:24:35 +0100 (MET)

> if responding agent is representing malicious services. 

This is done flexibly in SLP.  The granularity of trust can be broad
(say a group of SAs or DAs) or fine (individual SAs and DAs).  The
finer the granularity, the more keying material and 'SPIs' to manage.

> real-life action (phone call, hand delivery, etc).  

It is true there is no automated certificate delivery mechanism today.
But wait - we have a service discovery protocol.  We could allow SLP
to distribute keys itself very easily - with no protocol extensions.
This could be done by having agents initially communicating with a
new SA or DA sending a SLP request to them.  This could obtain the
public key certificate for the SA and DA for all 'SLP SPI's the SA
or DA supports.

All the SLP agent would need to enable this would be a 'site CA 
certificate'.  This could be used to verify the SA or DA certificate.
Once verified, the SLP agent could use the SA or DA public key (and
SPI value) to validate auth blocks produced by the SA or DA.

If there is interest, we can proceed to define a service type
representing the SLP security configuration for agents.  A tool
(generating DSA public key/private key pairs) in string encoded
cert format would enable a site administrator to generate the
'CA key' as well as the 'SLP agent keys.'  

This is not a perfect solution.  It leaves out the issue of 
key revocation and finer details of certificate management.
Perhaps the best thing to do here is to look toward the PKIX
WG to provide a solution rather than considering spinning our
own.  See http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-04.txt
for example.

> considered an optional feature.

It is certainly an option (in some deployments) to leave security to
the applications themselves.  But in other scenarios this is not 
appropriate, as when clients do not want to even bother contacting
(or shouldn't reveal themsleves to) services which are not authenticated.

It is not an option to remove SLP security from the protocol moving
forward to Draft Standard.  We have to arrive at interoperable 
SLP security to achieve it, however.  It may be necessary to clarify
the protocol to achieve this.

Erik

---

From: Matt Peterson <[email-masked]>
Date: Fri, 26 Jan 2001 09:56:27 -0700

> SPI value) to validate auth blocks produced by the SA or DA.

Who or what delivers the site CA certificate?  Again this requires
personalized administrative contact -- which is not a big deal if it
only needs to occur one time.  What would be great is if there were some
sort of API that could be used to obtain existing key material and use
it in SLP implementations without requiring each application (SSH, SSL,
PGP, ... now SLP) to reestablish trust.  (Sounds like this is the goal
of the PKIX draft you mention below).

> own.  See http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-04.txt

I definitely think that we should look to a standardized solution rather
than rolling our own for SLP.  Distribution of key material something
that will be of interest to many other protocols and applications.  It
is preferable to use something standardized and reusable so that
administrators only have to distribute key information once (not over
and over for every protocol / application that uses a different
system).  

Currently I generate, distribute and manage keys for SSH, SSL, PGP,
etc... and now for SLP -- which is supposed to be "plug and play"?  I
hope not.

The point of this thread was to suggest that in the absence of
standardized PKI is it OK for SLP to expect service specific software
and protocols to perform authentication by themselves if they care about
this level of security (SSH, SSL, etc...)   In other words, if the
desired feature of SLP is usability (plug-and-play), then SLP
authentication can be sacrificed without reducing overall security if
applications that care about security handle distribution of key
material and trust establishment. 

> the protocol to achieve this.

I agree fully.  Security is an important feature of the protocol and
must not be considered for removal.  The arguments I make in this thread
are more related to deployment and implementation in standard networking
settings.  As you mention above, there are applications where
distribution of key material is much easier than it is currently in
normal PC / LAN / enterprise settings.  In these cases SLP
authentication does not affect the usability of the protocol.  Likewise,
when standardized distribution of certificates is available in standard
networking settings, then general SLP authentication usage on enterprise
LANs won't be a problem either.  

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

---

From: Erik Guttman <[email-masked]>
Date: Sat, 27 Jan 2001 15:35:47 +0100

> only needs to occur one time. 

Security doesn't come for free - it requires configuration.  I suggest
all one has to do is configure an agent once (give it a site CA
certificate,
a set of "SLP SPI" names and SLP scopes to use, etc.)

> What would be great is if there were some
> PGP, ... now SLP) to reestablish trust. 

There is no unified security architecture for IETF protocols.  Its
unclear
whether there can be, given the very different requirements of different
protocols.   SLP uses multicast and store/forward of service
advertisements.
This means SLP needs 'object' rather than 'transport' level security.

> than rolling our own for SLP. 

Agreed.  I tried to embark on this in SLPv1 (see RFC 2165 which proposes
a policy for key management and a certificate format.  The next step 
would've been certificate distribution.  There was basically no interest
so we dropped this in SLPv2.)

> etc... and now for SLP -- which is supposed to be "plug and play"?  I

We are going to try to start work on an IPsec-centric approach for 
ZEROCONF, which would allow a single configuration event (with attention
to making it easy for humans to accomplish) to secure IP.  This would
primarily be for securing zeroconf protocols (address autoconfiguration,
etc.) but could be used for application layer protocols as well.

My feeling is that SLP will probably be deployed without authentication
in most cases.  Keys will be distributed for specific services for which
it would be intolerable to accept 'masqueraded' service advertisements.
For instance, the SA advertising 'secure audit/log servers' might be
worth 
the trouble of configuring with keys, as well as the clients which have
to 
locate these log servers.  There are lots of other examples:  Printers
which will sent sensitive data, file servers for saving sensitive files,
etc.  This depends on the policy and requirements of individual sites.

Our challenge, as you point out, is to make the protocol as easy to 
configure as possible.  Providing an API for and specifying the use of, 
say, PGP keys, might ease deployment where PGP keys are already being 
used.

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: [email-masked]
Sr Staff Engineer, Sun Microsystems       Email: [email-masked]
Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497