HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:13:55 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 07 Dec 1999 14:59:00 GMT ETag: "2e9a9a-4951-384d20b4" Accept-Ranges: bytes Content-Length: 18769 Connection: close Content-Type: text/plain Internet Engineering Task Froce Erik Guttman INTERNET DRAFT Sun Microsystems 8 December 1999 Expires in six months Vendor Extensions for Service Location Protocol, Version 2 draft-guttman-svrloc-vendor-ext-00.txt Status of this Memo This document is an individual contribution for consideration by the Internet Engineering Task Force. Comments should be submitted to the svrloc@svrloc.org mailing list. This document is intended to be submitted to the IESG for consideration as an Informational RFC. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Copyright (C) The Internet Society 1999. All Rights Reserved. Abstract The Service Location Protocol, Version 2 [1] contains a number of features which are left up to vendors. This document describes how each of these features can be used safely (with no possibility of name collisions). This document also describes how vendors can extend the protocol safely without requiring any IETF standardization work. Finally, this document defines a new extension to the SLPv2: The Vendor Opaque extension. E. Guttman Expires: 7 June 2000 [Page 1] Internet Draft Vendor Extensions for SLPv2 December 1999 Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology . . . . . . . . . . . . . . . . . . 2 2.0 Enterprise Numbers . . . . . . . . . . . . . . . . . . 3 3.0 Naming Authorities . . . . . . . . . . . . . . . . . . 3 4.0 Vendor Defined Attributes . . . . . . . . . . . . . . 4 5.0 Vendor Opaque Extension . . . . . . . . . . . . . . . 5 5.1 Vendor Opaque Extension Format . . . . . . . . . . 6 5.2 Example: Acme Extension for UA Authentication . . 6 6.0 Extensions Requiring IETF Action . . . . . . . . . . . 7 7.0 IANA Considerations . . . . . . . . . . . . . . . . . 8 8.0 Security Considerations . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 1.0 Introduction The Service Location Protocol, Version 2 [1] defines a number of features which are extensible. This document clarifies exactly which mechanisms can be used to that end (Sections 3-5) and which cannot (Section 6). Conventions are specified which ensure that the protocol extension mechanisms in the SLPv2 specification will not possibly have ambiguous interpretations. This specification introduces only one new protocol element, the Vendor Opaque Extension. This Extension makes it possible for a vendor to extend SLP without having to engage in any standardization efforts or bureaucratic activity whatsoever once the vendor has registered itself with IANA and obtained an Enterprise Number. 1.1 Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2]. E. Guttman Expires: 7 June 2000 [Page 2] Internet Draft Vendor Extensions for SLPv2 December 1999 Service Location Protocol terminology is defined in [1]. IANA registration terminology is defined in [6]. 2.0 Enterprise Number Enterprise Numbers are used to distinguish different vendors in IETF protocols. Vendor Extensions to SLPv2 will use these values to avoid any possibility of a name space collision. Each vendor is responsible for ensuring that vendor extensions under their own authority are non-conflicting. RFC 1700 lists the Enterprise Numbers registered at the time of publication as well as rules on how to register new numbers: To request an assignment of an Enterprise Number send the complete company name, address, and phone number; and the contact's person complete name, address, phone number, and email mailbox in an email message to . [3] The complete up-to-date list is maintained by IANA [4]. All a Vendor must do is register their Vendor ID and they are then able to extend SLPv2 in many ways without requiring any additional interaction with any standards organization. 3.0 Naming Authorities Naming Authorities are defined by SLPv2 [1] as the agency or group which catalogues Service Types and attributes. A Service Type is a string representing a service which can be discovered by SLPv2 in a Service URL. Attributes may be associated with a particular service which is advertised by SLPv2. Service Type strings and service attributes may be registered with IANA by creating a Service Template [5]. The template is included in an internet draft and an email message is sent to srvloc-list@iana.org requesting that the template be included in the Service Template registry. In this case the naming authority for the service type is IANA. It is also possible for a Vendor to define their own naming authority. In this case, any service type or attributes may be used. SLPv2 allows arbitrary naming authorities to coexist. To use an explicite naming authority, a vendor simply their Enterprise Number as a naming authority. For example, for the following (fictitious) Enterprise Number 9999 Acme, Inc. Erik Guttman femur@neato.org E. Guttman Expires: 7 June 2000 [Page 3] Internet Draft Vendor Extensions for SLPv2 December 1999 the Naming Authority string to use would be "9999." A service: URL which used this Naming Authority to advertise a Roadrunner Detector service could look like service:roadrunner-detector.9999://neato.org:9341 Service types which are defined under a naming authority based on an Enterprise Number are guaranteed not to conflict with other service type strings which mean something entirely different. That is also true of attributes defined for service types defined under a naming authority. 4.0 Vendor Defined Attributes SLPv2 [1] suggests that Non-standard attribute names SHOULD begin with "x-", because no standard attribute name will ever have those initial characters. It is possible that two non-standard attributes will conflict that both use the "x-" prefix notation. For that reason, vendors SHOULD use "x-" followed by their Enterprise Number followed by a "-" to guarantee that the non-standard attribute name's interpretation is not ambiguous. For example, Acme, Inc.'s Enterprise Number is 9999. Say the Service Template for NetHive (a fictitious game) was: ------------------------------------------------------------ template-type=NetHive template-version=1.0 template-description= The popular NetHive game. template-url-syntax= url-path = ; There is no path for a NetHive service URL. features= string M O # The list of optional features the NetHive server supports. # Possible values are listed below. secure session, fast mode current-users= string M # The list of users currently playing ------------------------------------------------------------ Acme's server advertises a feature which is not on the list E. Guttman Expires: 7 June 2000 [Page 4] Internet Draft Vendor Extensions for SLPv2 December 1999 of standard features, "x-9999-cheat mode". Only an Acme client would know to request servers which support this mode since this attribute value is not standard. 5.0 Vendor Opaque Extension SLPv2 [1] defines a protocol extensibility mechanism. SLPv2 Extensions are added at the end of a message and have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension ID | Next Extension Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset, contd.| Extension Data / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Extension Data depends on the Extension ID. Refer to [6] for a full description of different mechanisms available for registration of values with IANA. Extension ID Range Assignment By Protocol Action 0x0000 - 0x3FFF Designated Expert Ignore Extension if Extension ID unrecognized 0x4000 - 0x7FFF Designated Expert Drop message if Extension ID unrecognized 0x8000 - 0x8FFF (No one!) Ignore Extension if Extension ID unrecognized 0x9000 - 0xFFFF (No one!) Reserved. Vendors may extend SLPv2 in any of three ways. First, they may define a new extension to SLPv2 in an internet draft. The vendor then requests that the IESG contact the designated expert for SLP who will review the document. If the document is sound, the document will be published as an Informational RFC with the new Extension ID assigned. An experimental extension may be done using the range 0x8000 to 0x8FFF. There is always the risk, however, that another vendor will use the same ID, since these IDs are not registered. Finally, the following OPTIONAL to implement extension allows a E. Guttman Expires: 7 June 2000 [Page 5] Internet Draft Vendor Extensions for SLPv2 December 1999 Vendor to define their own extensions which are guaranteed to have a unique interpretation. 5.1. Vendor Opaque Extension Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension ID = 0x0003 | Next Extension Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset, contd.| Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ent. #, contd.| Extension Data / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Enterprise Number is included in the Extension as a 4 byte unsigned integer value. The Extension Data following is guaranteed to have an unambiguous interpretation determined by the vendor. 5.2 Example: Acme Extension for UA Authentication For example, the Acme Corporation, whose Enterprise Number is 9999, can define three extensions to SLP to create an application level access control to service information. (Note that the first byte in the Extension Data is used to differentiate the different extensions under the authority of the vendor.) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID = 1 | Client ID Length | Client ID / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Acme UA multicasts a SLP request includes the Vendor Opaque Extension, with the Enterprise Number set to 9999 and the Extension Data as above. The Client ID is a string formatted in the Acme Client ID format (not described here). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Challenge = 2 | Challenge Length | Requester ID / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An Acme SA which receives a SLP request for 'restricted services' will ignore it unless the request includes a Vendor Opaque Extension with an Acme Client ID. In that case it sends a reply to the requesting UA with zero results and a Vendor Opaque Extension with the Enterprise ID set to 999 and containing the above "Challenge" data in the E. Guttman Expires: 7 June 2000 [Page 6] Internet Draft Vendor Extensions for SLPv2 December 1999 Extension Data. The challenge is in the Acme Challenge format (not described here). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response = 3 | Response Length | Response / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An Acme UA which receives a reply with zero results and a Vendor Opaque Extension with a "challenge", as above, may unicast a request to the SA which sent the challenge. The request will be the same as the initial one (which contained the "Client ID" Acme vendor extension), however in this case it will include a Vendor Opaque extension with the Enterprise Number set to 9999 and the Extension data including the "Response" data as above. The "Response" data is in the Acme format (not described here). The SA will then process the response and if the UA has authenticated itself, the SA will uncast a reply including the requested information. 6.0 Extensions Requiring IETF Action SLPv2 [1] defines a number of features whose modification cannot be done by simple vendor extension. These include: - Block Structure Descriptors (BSD) identifies the format of the Authenticator in the Authentication Block included in some SLP messages. BSD values from 0x0003-0x7FFF are assigned by IETF Consensus. - New function-IDs in the range 12-255 may be standardized by the method of IETF Consensus. - new error numbers in the range 15-65535 are assigned on the basis of a Standards Action. - New SLP Extensions with types in the range 4-65535 may be registered following the review of the Designated Expert. - New Service Types may be defined and registered with IANA following the review of the Designated Expert. See [5]. Terminology and procedures for registration of IDs with IANA are defined in [6]. Only changes to the base "required to implement" protocol require IETF Consensus. Extensions are all defined to be done using the approval of a Designated Expert, though in some cases this involves E. Guttman Expires: 7 June 2000 [Page 7] Internet Draft Vendor Extensions for SLPv2 December 1999 publishing an Informational RFC. 7.0 IANA Considerations This document discusses vendor extensibility to SLPv2 but does not introduce any new number or name spaces which need to be administered by IANA. The techniques described in this document make it possible for vendors to extend SLPv2 by doing nothing more than registering an Enterprise Number with IANA (as described in RFC 1700 [4]). 8.0 Security Considerations Vendor extensions may introduce additional security considerations into SLP. This memo describes mechanisms which are standardized elsewhere [1] [3] [5]. The only protocol mechanism described in this document (see Section 5 above) is no less secure than 'private use' extensions defined in SLPv2 [1]. The example in Section 5.2 above shows how Vendor Opaque Extensions can be used to include a challenge response mechanism to SLP so that SAs can enforce an access control policy using a cryptographicly secure authentication mechanism. This is merely an example and protocol details were intentionally not provided. A vendor could, however, create a mechanism similar to this one and provide additional security services to SLPv2 in the manner indicated in the example. References [1] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service Location Protocol, Version 2", RFC 2608, July 1999. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October 1994. [4] ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers [5] Guttman, E., Perkins, C., Kempf, J., "Service Templates and URLs", RFC 2609, July 1999. [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs, BCP 26, RFC 2434, October 1998. E. Guttman Expires: 7 June 2000 [Page 8] Internet Draft Vendor Extensions for SLPv2 December 1999 Author's Address Erik Guttman Sun Labs, Network and Security Center Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany Phone: +49 7263 911 701 Messages: + 1 650 786 5992 Email: erik.guttman@sun.com E. Guttman Expires: 7 June 2000 [Page 9]