You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
235 lines
11 KiB
235 lines
11 KiB
Simple Service Registration Transaction Integrity for SLPv2
|
|
============================================================
|
|
|
|
As described by RFC 2608, SLPv2 is designed to support integrity and
|
|
authentication of service location information. In fact, the full
|
|
implementation of SLPv2 security often exceed the requirements for many
|
|
SLP applications. In such cases, the requirements for distribution of key
|
|
material and security configuration challenges SLP's claim that:
|
|
|
|
"Using this protocol, computers using the [network] need little or no
|
|
static configuration of network services for network based applications."
|
|
|
|
-- RFC 2608 (abstract)
|
|
|
|
|
|
In order to provide SLPv2 security, it is necessary to distribute SPI and
|
|
key information to ALL agents (UAs SAs and DAs).
|
|
|
|
The SLP security Problem
|
|
-------------------------
|
|
|
|
|
|
SPI configuration
|
|
-----------------
|
|
An SPI is an arbitrary string that identifies a key material that is needed
|
|
to generate and verify digital signatures. Basically, a SPI is an alias for
|
|
a public/private key pair.
|
|
|
|
In order for SLPv2 security to work, there needs to be some way for the
|
|
implementation to map SPIs to keys and mapping must be saved in secure
|
|
storage. The formatting will vary, but the information represented by the
|
|
following table must be represented:
|
|
|
|
SPINAME = PUBLICKEY [PRIVATEKEY]
|
|
|
|
In the case of a UAs it is not necessary to configure a private key since
|
|
a UA does not generate signatures. The SA and DA do generate signatures
|
|
and must be configured with a private key for SPIs they support. All agents
|
|
need to be configured with a public key for SPIs they support.
|
|
|
|
It is evident from RFC 2614 that it is not intended for SPIs to be exposed to
|
|
developers. Since there are no standardized APIs to change SPI configuration,
|
|
it is always an implementation specific (and most likely manual) procedure.
|
|
It is also evident that SPI configuration is intended to be managed on a
|
|
per-SLP installation basis -- not on a per-application basis.
|
|
|
|
Key distribution
|
|
----------------
|
|
- keys (especially private) are difficult to distribute automatically.
|
|
|
|
SPIs and scopes related?
|
|
------------------------
|
|
Using SLP scopes allows administrators to create functional SLP "domains"
|
|
for administrative and scalability purposes. Scope configuration can be
|
|
statically configured, delivered via DHCP, or selected by the user.
|
|
Regardless, scope configuration is really the only peice of information that
|
|
is needed for a working SLP deployment -- unless the SLP deployment needs to
|
|
be secure.
|
|
|
|
SPIs allow administrators to create functional SLP "domains" of trust.
|
|
Conceptually, there would could be a one-to-one mapping of scopes to SPIs.
|
|
To reduce confusion, might be wise to use *exactly the same string* for the
|
|
scope and the SPI.
|
|
|
|
SPI Hell
|
|
---------
|
|
Perhaps the reason SPI configuration standards were not treated in the RFCs is
|
|
because it would be very difficult (if not impossible) to come up with a
|
|
standard that would address the needs of SLP deployments. Imagine the
|
|
differences between the way that SPI configuration would be performed for
|
|
the following: a desktop computer, a fileserver, a printer, a cell phone (or
|
|
other embedded device).
|
|
|
|
The best way to avoid confusion is to simply not use SLPv2 security. This
|
|
is true for implementors of the SLPv2 protocol as well as for developers
|
|
that write to the SLP API.
|
|
|
|
Current SLP security requirements
|
|
----------------------------------
|
|
SLPv2 security as described by RFC 2608 supplies -- at the protocol
|
|
level -- everything that is needed to ensure that service location information
|
|
was sent by a trusted entity (authentication) and that it is not changed in
|
|
transit (integrity). At the application level, this means that an
|
|
application developer (probably using the SLP API) can trust *all* SLP
|
|
delivered information.
|
|
|
|
Blind trust of SLP deliverd information (URLs, etc) is especially significant
|
|
in common situations where confidential information (username and password)
|
|
are exchanged with an entity authenticated only by the fact that it was
|
|
located via secure SLP.
|
|
|
|
For example, LDAP enabled software uses SLP to locate an LDAP directory. If
|
|
SLP information is secure, the username and password to establish a connection
|
|
with the LDAP directory can be sent with out having to use any other method to
|
|
establish the identity of LDAP directory. However, with LDAP (and many other
|
|
protocols, however, possible to establish the identity even if the SLP
|
|
information is not trusted. In fact, for any SSL or equivilant transport
|
|
establishing the identity of the "other side" seperatly from the URL used.
|
|
|
|
Most secure applications already have authentication built into their
|
|
protocols. In these cases, additional configuration for SLP to provide
|
|
another layer of authentication does not make sense.
|
|
|
|
Security by fear
|
|
----------------
|
|
Most Internet security problems are approached with the assumption that no
|
|
one is trustworthy and that no one is trackable or accountable. This is
|
|
probably not an appropriate approach to SLP security because SLP is not
|
|
intended for the Internet.
|
|
|
|
SLP is intended to function within networks under cooperative
|
|
administrative control. Such networks permit a policy to be
|
|
implemented regarding security, multicast routing and organization of
|
|
services and clients into groups which are not be feasible on the
|
|
scale of the Internet as a whole.
|
|
|
|
-- RFC 2608 (section 1.1 Applicability Statement)
|
|
|
|
In approaching the SLP security problem, one should continue to assume that
|
|
no one is trustworthy, however, it SHOULD NOT be assumed that no one is
|
|
accountable or trackable. In fact, in "networks under cooperative
|
|
administrative control" it is very easy track and confront individuals that
|
|
corrupt otherwise insecure systems as long as it can be identified that a
|
|
corruption has been attempted or has occured. Because they can be held
|
|
accountable, fear of consequences keep otherwise untrustworthy individuals
|
|
in line.
|
|
|
|
The real SLP security problem
|
|
-----------------------------
|
|
The use of secure service specific protocols/frameworks in an environment
|
|
"under cooperative administrative control" greatly reduces the scope of the
|
|
Security problem. Instead of having to ensure that every bit of SLP
|
|
information is delivered with authenticity and integrity, SLP only has to
|
|
worry about a small portion of the SLP delivered information is delivered
|
|
with authenticity and integrity -- and this is only so that developers (and
|
|
ultimately system administrators) can be *alerted* to SLP related attacks.
|
|
|
|
Continuing the LDAP example from above, it is possible to write a secure LDAP
|
|
enabled "client" application that uses "insecure" SLP to discover the LDAP
|
|
server. The client would locate URLs for *all* LDAP services using SLP.
|
|
The client would try to establish an SSL connection with each of the
|
|
discovered LDAP servers until an LDAP server that comes to an LDAP server
|
|
that is trusted. If SLP finds an LDAP servers that is not trusted it should
|
|
display a warning message (thus helping to track down the rogue or
|
|
misconfigured LDAP server).
|
|
|
|
In the example above there is one no chance for security compromise in
|
|
the LDAP application due to it's use of SLP. There is, however a chance that
|
|
an attack could burdon the application. The following is a list of attacks
|
|
that can not be prevented without addtions to the required SLP implementation:
|
|
|
|
Unauthorized Registration - An obvious attack of registering many
|
|
non-existant LDAP services which would result in the application taking
|
|
a long time to connect to LDAP (it would probably have to iterate through a
|
|
lot of bogus services before it found a valid one).
|
|
|
|
Unauthorized Deregistration - A more effective attack would be to simply
|
|
de-register the valid registration so that no LDAP services would be found
|
|
at all.
|
|
|
|
Unauthorized Reregistration - Reregister the LDAP service with different
|
|
attributes. (This attack would only affects applications that rely on
|
|
SLP attributes)
|
|
|
|
Unauthorized DA - Bring up an unauthorized DA that has been modified to
|
|
achieve the same results as the above mentioned attacks.
|
|
|
|
Unauthorized SA - Bring up an unauthorized SA that has been modified to
|
|
achieve the same results as an unauthorized registration or
|
|
re-reregistration (only a problem if the application relies on SLP
|
|
attributes)
|
|
|
|
Scrambler in the middle - Malicious party that "sniffs" the network and
|
|
intentionally scrambles valid messages so that they become invalid.
|
|
|
|
|
|
Full SLPv2 security implementation prevents all of the above attacks except
|
|
the "scrambler in the middle attack" which is not preventable. However, in
|
|
order to do it, the full SLPv2 security imposes the SPI configuration and key
|
|
distribution overhead that was discussed earlier.
|
|
|
|
The solution to the SPI and the key distribution problem is to simply not
|
|
use SLPv2 security as defined in the RFC or expect that the world will
|
|
standardize on a single SPI and key distribution solution and that tools can be
|
|
written to automate them. Perhaps the best advise for those trying to write
|
|
SLP software today is to simply not use SLPv2 security as defined by the RFC
|
|
and spend the time implementing or using secure service-specific transport or
|
|
presentation layer protocols. As long as service-specific protocols are
|
|
secure, there is no chance that sensitive data or resources will be
|
|
compromised.
|
|
|
|
Careful use of normal (insecure) SLPv2 can supply enough information
|
|
to warn administrators about "unauthorized registration" attacks and
|
|
"unauthorized SA/DA" attacks, but currently, without a simple security
|
|
enhancements (in addition to normal SLPv2) it is impossible to prevent
|
|
any of these attacks or to even detect "unauthorized de-registration" or
|
|
"unathorized re-registration" attacks.
|
|
|
|
Solution
|
|
--------
|
|
"Simple Service Registration Transaction Integrity for SLPv2" (SSRTI-SLPv2) is
|
|
a really long name for a very simple security extension to SLPv2 protocol that
|
|
facilitates prevention or dection of all the SLP attacks that would otherwise
|
|
"burdon" (not compromise) SLP enable software.
|
|
|
|
Prevented by SLPv2 security
|
|
unauthorized registration
|
|
unauthorized deregistration
|
|
unauthorized reregistration
|
|
unauthorized SA
|
|
unauthorized DA
|
|
first registration wins (not applicable)
|
|
man-in-the-middle
|
|
|
|
Prevented by SSRTI-SLPv2:
|
|
unauthorized deregistration
|
|
unauthorized reregistration
|
|
|
|
Detectable by application developer:
|
|
unauthorized registration
|
|
unauthorized SA
|
|
|
|
Deterrable by implementation:
|
|
unauthorized registration
|
|
first registration wins
|
|
|
|
Detectable by implementation:
|
|
unauthorized DA
|
|
|
|
Not preventable or detectable
|
|
scrambler-in-the-middle
|
|
|
|
(Remember the Registration replay attack!)
|
|
|