Subject: SPI Question

From: "Joseph Campolongo" <[email-masked]>
Date: Wed, 27 Oct 1999 15:00:16 -0700

I'm wondering exactly what and SPI is.

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.

Could somebody please give me a hand here?

Joseph Campolongo
[email-masked]

---

From: Erik Guttman <[email-masked]>
Date: Thu, 28 Oct 1999 12:57:25 +0200 (MET DST)

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

> "key length, algorithm parameters and keying material", although I have no

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

---

From: "Michal Morciniec" <[email-masked]>
Date: Fri, 29 Oct 1999 13:12:50 +0100

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

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

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.

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

Thanks for your help

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Erik Guttman
> Sent: Thursday, October 28, 1999 11:57 AM
> To: Joseph Campolongo
> Cc: [email-masked]; [email-masked]
> Subject: Re: SPI Question
>
>

---

From: Erik Guttman <[email-masked]>
Date: Fri, 29 Oct 1999 16:05:54 +0200 (MET DST)

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

> (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