Subject: SLP SPI strings

From: Matt Peterson <[email-masked]>
Date: Fri, 22 Dec 2000 11:36:04 -0700

Can anyone help me out by directing me to a properly formed SLP SPI
string (something that can be used to supply parameters for BSD=0x0002 -
DSA with SHA-1 ).  Looks authentication support is going to be
implemented in OpenSLP sooner than I thought.

If no examples (hopefully sample code) exist, maybe I just need a short
SPI tutorial...  An SLP SPI (at least the one for BSD 0x0002) appears to
be something that must conform some sort of standard right?

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

---

From: Erik Guttman <[email-masked]>
Date: Fri, 29 Dec 2000 14:48:46 +0100 (MET)

I looked back through my archive of mails on the subject to find the 
pointers to the archive to send you.  To my surprise, lots of mail 
sent to the archive never made it there.  1999 seems to have entirely
disappeared.  I'll look into this...

In the meantime I am attaching 4 emails I sent clarifying the SLP SPI
to folks over the past year or so.  I think this points to the need for
better explanation in RFC2608bis.

> DSA with SHA-1 ). 

That string can be anything you want, say "foo".  If a UA issues a
request with the SLP SPI string set to "foo" a DA will only return
SrvRply or AttrRply messages containing authentication blocks which
also have the string "foo" in them.  

That means that somewhere there must be SAs which are configured to 
generate authentication blocks with the "foo" SLP SPI string in them.

The configuration in the deployment looks like this.  

 - Create a public/private key pair using DSA tools and 
 - name it, say "foo".  
 - Distribute the public "foo" key to UAs and DAs likely need to use it.  
   For example, maybe the UAs and DAs in scopes "west" and "central".
 - Distribute the private "foo" key to the SA or SAs.  This SA or these
   SAs are *explicitely annointed as trustworthy* by this distribution.

A UA which requests a service using a multicast request, using the
SPI SPI "foo" will cause the SA (or SAs) configured with the "foo"
private key to respond - and only those.  The SA (or SAs) will respond
with a SrvRply or AttrRply containing an authentication block which the
UA can verify, as it has the public key corresponding the SA's private
key, for "foo".

A DA which receives a registration with an authentication block will
check it, if the DA has been configured with the SPI SPI in the auth
block.  For example, a DA configured with the public key for "foo"
would check an SA's registration, deregistration or update for "foo" 
before accepting it.  This will prevent malicious alteration or 
deregistration of a legitimate SA's service registration.

> SPI tutorial...  

How about some text from implementors - which we can include in the
update to RFC 2608?!

> An SLP SPI (at least the one for BSD 0x0002) appears to

Yes!

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

Date: Mon, 28 Aug 2000 20:50:20 +0200 (MET DST)
From: "Erik Guttman" <[email-masked]>
Subject: Re: SLP v2 security
To: "Matt Peterson" <[email-masked]>
Cc: [email-masked]

> Erik,
> 
> In an attempt to keep the OpenSLP design open to the possibility of full
> SLP v2 security support, I have been re-reading section 9.2.
> (Authentication Blocks).  I have always wondered, and hoped to find out
> with this latest reading of the RFC, how SLPv2 authentication blocks
> ensure a messages has been transmitted by an authorized agent.  

There are two classes of entity.  The signer and the verifier.  These
have to share security configuration.  This configuration is 'named'
with a SLP SPI.  

The verifier says:  I want data which can be returned with a digital
signature created by signers (holders of the private key associated
with the SPI). 

SAs or DAs see this request and determine if they can generate such
a signature.  Do they have private key associated with the SLP SPI
in the request?  If so, they send the reply and the auth block.

The verifier checks the digital signature using the private key associated
with the SLP SPI.  If its OK, they accept the message.

Note that you could specify a new mechanism (other than DSA with SHA-1)
that used symmetric keys.  In this case, any verifier could also be a
signer, which may be acceptable for certain security policies.
 
> I think I understand how the Authentication blocks can ensure that the
> data was not changed in transit, but I can not see how AuthBlocks can
> give any assurance that the message was transmitted by an authorized
> agent with out some sort of key exchange between the transmitting and
> receiving agent.  How is a set of authized agents established with out
> user or administrator input?  Am I missing something or are
> Authentication Blocks really just "data integrity blocks"?

They are more than integrity blocks since only those who have the
necessary keys can create the signature.  That is, we can show more
than that the message wasn't modified in transit, but also that it
is 'authentic' with respect to an identity with whom we have previously
established trust (through the distribution of keys by a trusted network
administration).

We implemented SLP security at Sun.  It would be really great to get
interoperability going.  Are you interested in participating in a SLP
interop test later in the year?  We'll need to show interoperability
for every protocol feature we want to have in the spec going to draft
standard.  Sun could sponsor the testing, in California.

> Please explain.

I hope the above suffices.
 
Erik

Date: Tue, 28 Nov 2000 15:32:04 +0100 (MET)
From: "Erik Guttman" <[email-masked]>
Subject: Re: SPI in SLP
To: "Marco Vettorello" <[email-masked]>
Cc: "Erik Guttman" <[email-masked]>

> Hello Mr.Guttman!
> Thank you for advising me about the Cryptlib package.
> It's been hard to find out how to work with the library, but I finally
> managed it. Now it's time to implement the algorithm in an SLP beta
> version here at my institute.

Cool.  If you can give away your implementation (or share it with me)
I'd be grateful.

> Personally, I think it would be better to write the public/private keys
> into a static file,from where all agents can read them and use them to
> verify the signature,instead of sending them within each message. So,
> the only content of the SPI string would be the password needed to read
> the keys from the file.

The idea is that you only send a string like "bob" with each message -
as the SPI.  Here is a little picture.

   UA                         SA                      DA
     SPI    Key                 SPI    Key              SPI    Key
    "bob"  pub-key-bob         "bob"  priv-key-bob     "bob"  pub-key-bob
    "sue"  pub-key-sue         "sue"  pub-key-sue      "sue"  priv-key-sue

0 The UA, SA and DA are *preconfigured* with the tables shown above,
  associating keys with SPI strings.

1 The UA requests services using "bob" and "sue".

2 The SA signs SrvRply, AttrRply, SrvReg and SrvDeReg, using the
  private key associated with the string "bob."   The string "bob"
  and the authentication block are returned to the UA.

3 The UA verifies the Authentication block in the reply using the
  public key associated with the string "bob".

  If the UA could not verify the SA's reply using the public key
  associated with "bob", the UA would discard the SA's response.

4 The DA sends an unsolicited DAAdvert.  It signs the DAAdvert using
  the private key associated with the string "sue" and includes the 
  SPI string "sue" in the DAAdvert

5 Both the UA and the SA can verify the DAAdvert since they have a 
  public key associated with the SPI string "sue"

  If the authentication block of the DAAdvert could not be verified,
  the UA and SA would reject the DAAdvert instead of associating it
  with DAs which are authenticated.

6 The SA registers a service with the DA.  The registration includes
  the SPI string "bob" and an authentication block for the URL and
  for the attributes.  The SA produces a digital signature using the
  private key associated with the SPI string "bob"

7 The DA has a SPI string "bob" configured.  The DA uses the public 
  key associated with it to verify the authentication blocks in the
  SA's service registration (URL and attributes).  

  If the SA's auth blocks failed, the DA would reject the advertisement
  and return an error in the SrvAck.

8 The DA stores the authenticators registered by the SA.

9 When a UA requests a service with the SPI string "bob", the DA returns
  the data registered by the SA, along with the authenticators.  The UA
  will be able to verify the result exactly the same way as it did in 
  step 3 even though it is retrieving the reply from the DA instead of
  directly from the SA.

> Before I start programming, I'd like to know what you think: would this
> be possible?

I hope my description above helps.
 
> Thank you for your time.

No trouble at all!

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

Date: Thu, 28 Oct 1999 12:57:25 +0200 (MET DST)
From: "Erik Guttman" <[email-masked]>
Subject: Re: SPI Question
To: "Joseph Campolongo" <[email-masked]>
Cc: [email-masked], [email-masked]

> I'm wondering exactly what and SPI is.
> 

An SPI is a string which indicates (is an index to) a set of
security parameters.

Since we are deploying SLP security with a single site, we can
make some interoperability assumptions.  Note that these have
to do with the use and naming of the parameters not with their
interpretation.  Since SLP defines least required to implement
protocols for SLP authentication, if the device supports this,
it will certainly interoperate.

Let's take an example:

A SA advertises a service S.  It has been configured with
a private key to sign its advertisements.  A corresponding
public key is required to verify the signature.  This correspondence
is signified by a SPI string.  

SA:

   Private Key  BSD  Associated SPI
    privkey-1    2     VIP-office

UA:

   Public Key   BSD  Associated SPI
    pubkey-1     2    VIP-office

The UA issues a request for a service, listing the "VIP-office"
SPI.  The SA uses the private key to sign the reply as it assumes
that the UA has the corresponding public key.  

Had the UA requested a service using the SPI "Copy-Room" the SA
would not have responded.  This is according to the rules of SLPv2:
The SA can only produce signatures for UAs which are configured with
security parameters corresponding to "VIP-Office".  

Any other parameters which are required can also be associated with
the SPI - such as intialization vectors for cryptographic algorithms
or whatever.

Name collisions can be managed as we are deploying them only within
a single site.  

The reason that the BSD and the SLP SPI are separate is to explicitely
list the algorithm associated with the SPI.  This allows interoperation
with SLPv1 and the ability for the UA to be sure the calculation is worth
the effort (it won't need to start to process an authentication block with
the wrong BSD.)

> In RFC 2608 (SLPv2), it states that the
> 
>      Security Parameters Index (SPI) string identifies the
>      key length, algorithm parameters and keying material
>      to be used by agents to verify the signature data in
>      the Structured Authentication Block.  The SLP SPI string
>      has the same grammar as the <scope-val> defined in
>      section 6.4.1.
> 
> Also,
> 
>      SLP SPI's deployed in a stie MUST be unique.
> 
> And,
> 
>      The SA supplies a SLP SPI in each authentication block
>      indicating the SLP SPI configuration required to verify
>      the digital signature.
> 
> From what I can tell, the SPI is just an arbitrary string that acts as a key
> value to identify which Block Structure Descriptor to use.  What is
> confusing is that this cannot be the case, or else the SPI would just be the
> BSD, and wouldn't be some string.  Also, the SPI is supposed to identify the
> "key length, algorithm parameters and keying material", although I have no
> idea how.

It identifies it since a site administrator assigned the SPI name to
a set of parameters (one set for SAs, another for UAs) and then used
some key distribution technique to get the keys to the appropriate
agents.
 
> Could somebody please give me a hand here?

I hope this helps. 

Erik

Date: Fri, 29 Oct 1999 16:05:54 +0200 (MET DST)
From: "Erik Guttman" <[email-masked]>
Subject: Re: SPI in SLP integration with PKI
To: "Michal Morciniec" <[email-masked]>
Cc: "Erik Guttman" <[email-masked]>, "Joseph Campolongo" <[email-masked]>, [email-masked]

> Dear Eric,
> Are the UA authenticated by SAa or DAs in any way? It seems to me that
> only SAs and DAs sign anything because the only messages containing the
> authenticator are SrvRply, SrvReg, SrvDereg (through serviceURL entry)
> and SrvAttrRply, SAAdvert and DAAdvert (through attribute list).

That is correct.  UAs only check signatures.  SAs sign SrvReg, SrvDereg,
SrvAttrRply and SrvRply and potentially AttrRply.  DAs sign only DAAdverts. 
SAs may also check signatures (of DAAdverts).

> Is it true to say that there is no provision for authentication of
> senders of messages SrvRqst, SrvAck, SrvTypeRqst, SrvTypeRply, AttrRqst
> (because they do not contain signed objects - only SPI string)?

SLP contains no provisions for authentication of the UA requesting
information, nor for authenticating SrvAck messages.  SrvTypeRply
was not deemed to be critical (that is, it won't mislead anyone about
the existence or capabilities of any particular service).

> I wonder what are the implications of that for SLP with PKI key 
> management.  It looks like issuing the certificate to SAs and DAs 
> can improve trust but if a certificate is issued to UAs it does 
> not because UAs never uses the private key to sign anything.
> For example suppose SA has a certificate SA_12 and receives a 
> SrvRqst with from UA which has a certificate UA_101.

The use of certificates does help:  If the UA has a certificate 'C' which
was installed by the site manager, then it might be possible to have
each SA and DA have a *separate* private key and to provide either their
certificate 'C1' which is *signed by* C, or simply include the name 'C1'
and have the UA to use some PKI to retrieve it.  Either way, you have
one certificate to install in the UA and can use distinct keys for each
SA.  Note that the current protocol could support this:  The signature
in the authentication block is in X.509 format which allows the inclusion
of certificate, I believe.

> Would then the correct use of the SPI be that if UA sends SrvRqst to 
> SA it should include SPI=SA_12 and that SPI=UA_101 would never appear 
> in any message (because of lack of authentication mechanisms for UAs 
> by DAs and SAs by the protocol) ?

The idea is that the UA would send a request with an SPI like "Accounting
Department".  Say the SA had advertised >0 services signed by a DSA private
key which could be verified by the use of the "Accounting Department" public
key.  These services are candidates to return to the UA in SrvRply or
SrvAttrRply messages (if of course the SrvRqst or SrvAttrRqst matches the
scope, service type, language and so on, of the service advertisement.)

> Thanks for your help

My pleasure.

Erik