IPP> FW: WG LAST CALL: Service Location Protocol, Version 2

IPP> FW: WG LAST CALL: Service Location Protocol, Version 2

IPP> FW: WG LAST CALL: Service Location Protocol, Version 2

Ira Mcdonald x10962 imcdonal at eso.mc.xerox.com
Fri Oct 16 12:15:21 EDT 1998


>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





More information about the Ipp mailing list