Subject: Re: Treatment of multiple SLP Authentication blocks (long)

From: Erik Guttman <[email-masked]>
Date: Tue, 24 Apr 2001 20:39:36 +0200 (MET DST)

Matt,

I'm sorry I am slow in responding to your mail.  I have been on a long
business trip followed by a vacation.

> Can you please clarify the treatment of multiple authentication blocks as
> RFC 2608 is not completely clear on the subject.
>
> If I am not mistaken, authentication blocks are included in SrvReg,
> SrvDeReg, SrvRply, AttrRply, SAAdvert and DAAdvert messages.  In all of
> these messages it appears as though more than one authentication block can
> be included.  The exact number of authentication blocks is designated by 
> the 8bit "# of URL auths field" of the URL Entry and the "# AttrAuths
> field" of following attr-lists.

Yes.  This number can be zero - in which case no authentication blocks 
follow.

> In order for a message to be authentic do ALL authentication blocks have
> to be verified, or does only one of the authentication blocks need to be
> verified to trust the contents of the message?

RFC 2608 does not address this, I agree.  I could say it is a policy
question - the given agent may require either ANY or ALL SLP SPIs to
be authenticated.  

Do we need to hammer down the policy for SLP agents?  This could
be something like 

 - accept SrvReg and SrvDeReg only if ALL auth blocks for supported 
   SLP SPIs verify
 - accept DAAdvert, SAAdvert, SrvRply and AttrRply if ANY auth
   blocks for supported SLP SPIs verify

Let's look at why there may be multiple auth blocks in the messages.

In the case of a DAAdvert, messages are sent out passively.  There is no
way for a DA to know about the specific set of SLP SPIs supported by the
agents listening for DAAdverts on the network.  For this reason, it is
important for the DA to include all the auth blocks it can, with distinct
SLP SPIs, so that different UAs and SAs can authenticate the message.

This is also the case for SrvReg.  The service registered by a SA
may be requested by different UAs, each with different SLP SPIs.
The SA registers all the authentication blocks it can, so as to
maximize the set of UAs which can be served from the DA.  It is
also important to carry multiple auth blocks on 'refresh' 
registrations, so a DA can verify it is allowed.  This is the
same reason SrvDeReg carries multiple auth blocks.    A reasonable
thing for the DA to do would be to reject a registration if any
authentication block is missing or fails.

A UA will issue a request with at most one SLP SPI.

8.1. Service Request

   The <SLP SPI> string indicates a SLP SPI that the requester has been
   configured with. 

Section 10.3. Attribute Request

   The <PRList>, <scope-list> and <SLP SPI> string are interpreted as in
   Section 8.1.

This means that the URLEntry in SrvRply and the attribute list in AttrRply 
will include either 0 or 1 auth blocks.  The reason we include the # of
URLEntry auth blocks and Attrlist auth blocks in # auth blocks field is 
that this syntax is needed in the SrvReg message, and we wanted to be
consistent!

> Imagine a installation where a SA is configured with two SPIs
> "spi1" and "spi2" both of which are DSA-SHA1 (BSD 0x0002) only with
> different keys.  The DA is configured only with "spi1".  Should the DA
> accept registrations SRVREGs with 2 authblocks?  It only has to verify one
> (the one it has the SPI for) to be certain that the message is authentic.
> Why would it want to reject the registration because it can not verify all
> of the authblocks?

This part isn't ambiguous in RFC 2608:

   A SA configured with the ability to sign service registrations MUST
   sign each of the URLs and Attribute Lists using each of the keys it
   is configured to use, and the DA it is registering with accepts.
   (The SA MUST acquire DAAdverts for all DAs it will register with to
   obtain the DA's SLP SPI list and attributes, as described in Section
   8.5).  The SA supplies a SLP SPI in each authentication block
   indicating the SLP SPI configuration required to verify the digital
   signature.  The format of the digital signatures used is defined in
   section 9.2.1.

> I know that what you're going to say is that DAs provided a list of
> supported SPIs in the DAADVERT and that the SA could know to only send the
> SPI that the DA understands.  However, this needlessly complicates the
> implementation of the SA as it has to keep track of SPI information on a
> per DA basis.  This seems like wasted code in an SA since there is no
> security risk to any agent by sending both authentictors.
>
> In case you can't tell, I'm arguing for simplicity of SA by allowing DAs
> to accept messages with multiple authentication if *at least one* (not
> all) of the authblocks is valid.

I agree that the DA could simply drop the auth blocks it can't verify
and that would make the protocol simpler (for SAs).

> From section 8.1 (last paragraph) it says that if no SPI string is
> contained in the request then no authblocks should be included in the
> reply.  What is the reasoning for this?  Is this a MUST or a SHOULD?  It
> seems like it would not hurt to send the authblock because the
> receiver will just ignore it.

The section:

   The <SLP SPI> string indicates a SLP SPI that the requester has been
   configured with.  If this string is omitted, the responder does not
   include any Authentication Blocks in its reply.  If it is included,
   the responder MUST return a reply which has an associated
   authentication block with the SLP SPI in the SrvRqst.

It could be a SHOULD.  As written, it looks like a MUST.  I agree, it
would make SAs and DAs simpler if they just returned what they had,
basta.  It might make the replies pretty big though and cause them 
to overflow.

> Also from section 8.1 (last paragraph) it says that if an SPI string is
> included in the request then responder MUST return authblocks in its
> reply.  Is this supposed to be interpreted to mean that the responder MUST
> only send the authblock that is related to requested SPI?  

That is what it is supposed to mean.

> If so, why are there provisions for multiple authblocks in reply messages?

See above.  DAAdverts need them (since they are passive) and SrvReg &
SrvDeReg need them (since the DA may get requests for any of multiple
different SLP SPIs).  Normally requests only have one SLP SPI, so 
SrvRply and AttrRply would only need one auth block at most.  But they
use the same format as SrvReg (the URLEntry and the authenticator
for the attribute list) for consistency.

> Finally, is there any way that the current protocol can be manipulated in
> implementation to prohibit other hosts (or applications) from
> deregistering a registration made from another host (or application)?  I
> can not think of any way of doing this with out SPI hell or protocol
> extension.

With the current spec, you would have to assign different SLP SPIs
on a per SA basis.  In short, SPI hell.  Actually, you would not have
to use protocol extensions to do this.  You could define a new Block
Structure Descriptor whose structured authentication block included
some identity information for the SA, which would be included in the
calculation of the digital signature.  The DA could be configured
with a list of identities it accepts (an ACL, essentially).  The DA
will verify the identity in the srvreg/srvdereg is authentic by 
including the identity string in the signature calculation.

See DHCP authentication - draft-ietf-dhc-authentication-16.txt
(this mechanism doesn't require public key cryptography).

Should investigate defining a new BSD using precisely DHCP 
authentication as the mechanism?  This would allow the reuse
of code used for similar functions and not require separate
administration for the two.

Erik

ps.

The real reason we allow multiple auth blocks in replies in SLPv2
is to allow rekeying.  It is not feasible to require that all keys
be changed at once in the network.  

  Routine rekeying

  - Say we have deployed the key pair {OLD-Private, OLD-Public} 
    in the network, associated with the SLP SPI 'OLD'.  We want 
    to rekey, and use {NEW-Private, NEW-Public} instead (associated 
    with SLP SPI 'NEW').  We start by adding NEW-Public keys to the 
    UAs.  These UAs issue requests using a SLP SPI string 'NEW'.  
    SAs which have been rekeyed will respond with authentication 
    blocks generated with the NEW-Private key.  The UA can also
    issue a request using SLP SPI 'OLD.'  Non-rekeyed SAs will 
    respond with authentication blocks generated with the OLD-Private 
    key.  Once all SAs have been rekeyed, the UAs can again be 
    reconfigured - to support only the 'NEW-Public' key.  This is 
    laborious, but allows phased-in rekeying. 

  Rekeying due to a compromise

  - Following the previous example, UAs could be rekeyed with 
    NEW-Public and use the SLP SPI 'NEW' *only.*  This is because
    OLD-Private is believed to be compromised.  In this case, 
    these UAs would never receive multiple authentication blocks
    and would only accept messages whose authentication was 
    generated by the NEW-Private key.  Non-rekeyed UAs would
    still use the 'OLD' SLP SPI until they were rekeyed.