Subject: Treatment of multiple SLP Authentication blocks

From: Matt Peterson <[email-masked]>
Date: Thu, 29 Mar 2001 21:36:16 -0700 (MST)

Erik (and srvloc mailing list),

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.

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?

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?

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.

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.

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?  If so, why
are there provisions for multiple authblocks in reply messages?

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.

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