>From owner-srvloc at srvloc.org Fri Oct 16 08:49:19 1998
Return-Path: <owner-srvloc at srvloc.org>
Received: from zombi.eso.mc.xerox.com by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1)
id AA10851; Fri, 16 Oct 98 08:49:18 EDT
Received: from by zombi.eso.mc.xerox.com (4.1/SMI-4.1)
id AB16681; Fri, 16 Oct 98 08:40:50 EDT
Received: from wicked.neato.org ([198.70.96.252]) by alpha.xerox.com with SMTP id <62419(4)>; Fri, 16 Oct 1998 01:49:13 PDT
Received: from localhost (daemon at localhost)
by wicked.neato.org (8.8.5/8.8.5) with SMTP id BAA25631;
Fri, 16 Oct 1998 01:48:44 -0700 (PDT)
Received: by wicked.neato.org (bulk_mailer v1.5); Fri, 16 Oct 1998 01:48:04 -0700
Received: (from majordom at localhost)
by wicked.neato.org (8.8.5/8.8.5) id BAA25561
for srvloc-outgoing; Fri, 16 Oct 1998 01:47:46 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by wicked.neato.org (8.8.5/8.8.5) with SMTP id BAA25557
for <srvloc at srvloc.org>; Fri, 16 Oct 1998 01:47:41 -0700 (PDT)
Received: from Germany.Sun.COM ([129.157.168.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA01240 for <srvloc at srvloc.org>; Fri, 16 Oct 1998 01:47:05 -0700
Received: from sun-ffm by Germany.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk205)
id KAA12892; Fri, 16 Oct 1998 10:47:04 +0200
Received: from sun.com by sun-ffm (SMI-8.6/SMI-SVR4-se.fkk202)
id KAA24777; Fri, 16 Oct 1998 10:47:02 +0200
Message-Id: <36270923.A6D9F03A at sun.com>
Date: Fri, 16 Oct 1998 01:51:47 PDT
From: Erik Guttman <Erik.Guttman at Sun.COM>
Reply-To: Erik.Guttman at Sun.COM
Organization: Sun Microsystems
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4m)
Mime-Version: 1.0
To: srvloc at srvloc.org
Subject: WG LAST CALL: Service Location Protocol, Version 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-srvloc at srvloc.org
Status: R
The internet draft draft-ietf-svrloc-protocol-v2-09.txt
is now in WG last call.
The changes in the draft were the result of comments during
the last WG last call period.
The major change is to SLP security. We now identify all
security parameters in a SLP SPI string. This could be a
string identical with a scope, in which case the SLPv1
(and SLPv2 up to draft 8) 'protected scope' security policy
could be followed. This mechanism, however, allows other
security policies to be implemented later, such as one key
per site, one key per SA, names of trusted entities that
correspond to names retrievable using PKI, etc. The actual
impact on the protocol is minimal except that it adds a
field to requests specifying a SLP SPI (or no SLP SPI if
authentication is not desired). Otherwise, SLP SPIs simply
make security explicit (where it was implicit previously,
by the use of 'certain scopes.')
The change list is as follows:
A. Changes to security.
1. I removed all mention of protected scopes. There is no
longer any necessary connection between scopes and
authentication in the protocol. This does not *prevent*
an administration from configuring certain scopes to be
equal to SLP SPIs. In this case, the configuration and
requirements for keying are identical to the protected
scope requirements in SLPv1 and SLPv2 up to draft 8.
2. I added SLP SPI Strings to SrvRqst and AttrRqst. Requests
made specifying a SLP SPI will only match services
which can be returned with Authentication Blocks
which can be verified using the parameters associated
with the SLP SPI.
3. SAAdverts and DAAdverts list the supported SLP SPIs of
that agent. That is, for what SLP SPIs can that SA or
DA supply authentication blocks in conjunction with
SrvRply and AttrRply messages.
4. If a SrvReg includes Authentication Blocks which cannot
be verified by a DA, the DA returns an AUTHENTICATION_UNKNOWN
error. If a subsequent SrvReg includes a different SLP SPI
list than a prior one, the DA returns an AUTHENTICATION_ABSENT
error.
5. There is a SLP SPI String field in Authentication Blocks
instead of a protected scope string. This string is used
by any agent which receives the auth block to identify
what parameters to use to verify the signature.
6. Unicast SrvRqst, AttrRqst and SrvTypeRqsts which cannot
be responded to because they include a SLP SPI not supported
by the receiving SA or DA receive an AUTHENTICATION_UNKNOWN
error reply.
7. Configuration notes were changed to include SLP SPI for
DA discovery and for service discovery, as well as
configuration for SLP and DA Private Key configuration.
8. The security considerations were modified to include text
mentioning that SLPv2 doesn't mandate a policy, it provides
a mechanism flexible enough to implement different policies.
9. All authentication block formats, including data inputs for
authentication calculations were moved to a single section.
B. Other changes:
1. The length field of Option Offsets is now 3 bytes long, not
2 bytes long. This was an error in previous drafts. This
required the header to be rearranged so that the XID field,
etc. stayed in the same place. Now Language Tags are immediately
preceded by the length field consistent with all other strings
in SLPv2 (a good thing!)
2. DAAdverts can be solicited using unicast requests. An error
code was added. This is necessary so that UAs and SAs can
request DAAdverts directly after having been configured using
DHCP or a config file to know what the SLP SPIs & attributes
of a DA are.
3. Definitions of other security BSD types were removed.
4. Multicast TTL set at 255 not 32. Since the administrative
scoped address is used for multicasting there is no need to
limit the extent of the multicast range by a smaller TTL than
the max.
5. SAs MUST accept unicast requests - this was implied by not
explicit in subsequent drafts.
6. There were a couple slight inconsistencies in the grammars
with RFC 2234 (ABNF).
Please comment to the SRVLOC at SRVLOC.ORG list by Oct. 27.
Thanks,
Erik Guttman
SVRLOC WG Chair