Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2165

Service Location Protocol

Pages: 72
Proposed Standard
Updated by:  26082609
Part 3 of 3 – Pages 50 to 72
First   Prev   None

Top   ToC   RFC2165 - Page 50   prevText
18. Service Location Transactions

18.1. Service Location Connections

   When a Service Location Request or Attribute Request results in a UDP
   reply from a Service or Directory Agent that will overflow a
   datagram, the User Agent can open a connection to the Agent and
   reissue the request over the connection.  The reply will be returned
   with the overflow bit set (see section 4).  The reply will contain as
   much data as will fit into a single datagram.  If no MTU information
   is available for the route, assume that the MTU is 1400; this value
   is configurable (see section 22).

   When a request results in overflowed data that cannot be correctly
   parsed (say, because of duplicate or dropped IP datagrams), a User
   Agent that wishes to reliably obtain the overflowed data must
   establish a TCP connection with the Directory Agent or Service Agent
   with the data.  When the request is sent again with a new XID, the
   reply is returned over the connection.

   When registration data exceeds one datagram in length, the Service
   Registration should be made by establishing a connection with a
   Directory Agent and sending the registration over the connection
   stream.
Top   ToC   RFC2165 - Page 51
   Directory Agents and Service Agents must respond to connection
   requests; services whose registration data can overflow a datagram
   must be able to use TCP to send the registration.  User Agents should
   be able to make Service and Attribute Requests using TCP. If they
   fail to implement this, they must be able to interpret partial
   replies and/or reissue requests with more selective criteria to
   reduce the size of the replies.

   A connection initiated by an Agent may be used for a single
   transaction.  It may also be used for multiple transactions.  Since
   there are length fields in the message headers, the Agents may send
   multiple requests along a connection and read the return stream for
   acknowledgments and replies.

   The initiating agent is responsible for closing the TCP connection.
   The DA should wait at least CONFIG_INTERVAL_12 before closing an idle
   connection.  DAs and SAs SHOULD eventually close idle connections to
   ensure robust operation, even when the agent which opened a
   connection neglects to close it.

18.2. No Synchronous Assumption

   There is no requirement that one transaction complete before a given
   host begins another.  An agent may have multiple outstanding
   transactions, initiated either using UDP or TCP.

18.3. Idempotency

   All Service Location actions are idempotent.  Of course registration
   and deregistration will change the state of a DA, but repeating these
   actions with the same XID will have exactly the same effect each
   time.  Repeating a registration with a new XID has the effect of
   extending the lifetime of the registration.

19. Security Considerations

   The Service Location Protocol provides for authentication of Service
   Agents as part of the scope mechanism, and consequently, integrity of
   the data received as part of such registrations.  Service Location
   does not provide confidentiality.  Because the objective of this
   protocol is to advertise services to a community of users,
   confidentiality might not generally be needed when this protocol is
   used in non-sensitive environments.  Specialized schemes might be
   able to provide confidentiality, if needed in the future.  Sites
   requiring confidentiality should implement the IP Encapsulating
   Security Payload (ESP) [3] to provide confidentiality for Service
   Location messages.
Top   ToC   RFC2165 - Page 52
   Using unprotected scopes, an adversary might easily use this protocol
   to advertise services on servers controlled by the adversary and
   thereby gain access to users' private information.  Further, an
   adversary using this protocol will find it much easier to engage in
   selective denial of service attacks.  Sites that are in potentially
   hostile environments (e.g.  are directly connected to the Internet)
   should consider the advantages of distributing keys associated with
   protected scopes prior to deploying the sensitive directory agents or
   service agents.

   Service Location is useful as a bootstrap protocol.  It may be used
   in environments in which no preconfiguration is possible.  In such
   situations, a certain amount of "blind faith" is required:  Without
   any prior configuration it is impossible to use any of the security
   mechanisms described above.  Service Location will make use of the
   mechanisms provided by the Security Area of the IETF for key
   distribution as they become available.  At this point it would only
   be possible to gain the benefits associated with the use of protected
   scopes if some cryptographic information can be preconfigured with
   the end systems before they use Service Location.  For User Agents,
   this could be as simple as supplying the public key of a Certificate
   Authority.  See Appendix B.

20. String Formats used with Service Location Messages

   The following section supplies formal definitions for fields and
   protocol elements introduced in the sections indicated.

      Protocol Element                      Defined in         Used in
      -----------------------------------   ------------     ------------
      <Previous Responders' Addr Spec>      20.1             SrvReq
      Service Request <predicate>           5.4              SrvReq
      URL                                   20.2             SrvReg,
                                                               SrvDereg,
                                                               SrvRply
      <attr-list>                           20.3             SrvReg,
                                                               SrvRply,
                                                               AttrRply
      <Service Registration Information>    9                SrvReg
      <Service Deregister Information>      11               SrvDereg
      <Service Type String>                 20.2.1           AttrRqst
Top   ToC   RFC2165 - Page 53
20.1. Previous Responders' Address Specification

   The previous responders' Address Specification is specified as

      <Previous Responders' Address Specification> ::=
             <addr-spec> |
             <addr-spec>, <Previous Responders' Address Specification>

   i.e., a list separated by commas with no intervening white space.
   The Address Specification is the address of the Directory Agent or
   Service Agent which supplied the previous response.  The format for
   Address Specifications in Service Location is defined in section
   20.4.  The comma delimiter is required between each <addr-spec>.  The
   use of dotted decimal IP address notation should only be used in
   environments which have no Domain Name Service.

   Example:

         RESOLVO.NEATO.ORG,128.127.203.63

20.2. Formal Definition of the "service:"  Scheme

   A URL with a "service:"  scheme is used in the SrvReg, SrvDereg,
   SrvRply and AttrRqst messages in Service Location.  URLs are defined
   in RFC 1738 [6].  A URL with the "service:"  scheme must contain at
   least:

   <url> ::= service:<srvtype>://<addr-spec>

   where:

      service       the URL scheme for Service Location, to return
                    Replies.

      <srvtype>     a string; Service Types may be standardized
                    by developing a specification for the "service
                    type"-specific part and registering it with IANA.
                    See sections 20.2.1 and 3.3.

      <addr-spec>   the service access point of the service.  It is the
                    network address or domain name where the service can
                    be accessed.  See section 20.4.

   The "service:"  scheme may be followed by any legal URL. The a
   particular service.  The protocol used to access the service at the
   given service access <addr-spec> may be implicit in the Service Type
   name.  If this is not the case, the Service Type MUST be defined in
   such a way that attribute information will include all necessary
Top   ToC   RFC2165 - Page 54
   configuration and protocol information.  A User Agent MUST therefore
   be able to use either a "service:"  URL alone or a "service:"  URL in
   conjunction with service attributes to make use of a service.

20.2.1. Service Type String

   The Service Type is a string describing the type of service.  These
   strings may only be comprised of alphanumeric characters, '+', and
   Type names.

   If the Service Type name is followed by a '.'  and a string (which
   has the same limitations) the 'suffix' is considered to be the Naming
   Authority of the service.  If the Naming Authority is omitted, IANA
   is assumed to be the Naming Authority.

   Service Types developed for in-house or experimental use may have any
   name and attribute semantics provided that they do not conflict with
   the standardized Service Types.

20.3. Attribute Information

   The <attr-list> is returned in the Attribute Reply if the Attribute
   Request does not result in an empty result.

   <attr-list> ::= <attribute> | <attribute>, <attr-list>
   <attribute> ::= (<attr-tag>=<attr-val-list>) | <keyword>
   <attr-val-list> ::= <attr-val> | <attr-val>, <attr-val-list>

   An <attr-list> must be scanned prior to evaluation for all
   occurrences of the string "&#" followed by one or more digit followed
   by ';'.  See Section 17.1.1.

   A keyword has only an <attr-tag>, and no values.

   A comma cannot appear in an <attr-val>, as the comma is used as the
   multiple value delimiter.  Examples of an <attr-list> are:

         (SCOPE=ADMINISTRATION)
         (COLOR=RED, WHITE, BLUE)
         (DELAY=10 MINS),BUSY,(LATEST BUILD=10-5-95),(PRIORITY=L,M,H)

   The third example has three attributes in the list.  Color can take
   on the values red, white and blue.  There are several other examples
   of replies throughout the document.
Top   ToC   RFC2165 - Page 55
20.4. Address Specification in Service Location

   The address specification used in Service Location is:

     <addr-spec> ::= [<user>:<password>@]<host>[:<port>]

     <host>      ::= Fully qualified domain name |
                     dotted decimal IP address notation

   When no Domain Name Server is available, SAs and DAs must use dotted
   decimal conventions for IP addresses.  Otherwise, it is preferable to
   use a fully qualified domain name wherever possible as renumbering of
   host addresses will make IP addresses invalid over time.

   Generally, just the host domain name (or address) is returned.  When
   there is a non-standard port for the protocol, that should be
   returned as well.  Some applications may make use of the
   <user>:<password>@ syntax, but its use is not encouraged in this
   context until mechanisms are established to maintain confidentiality.

   Address specification in Service Location is consistent with standard
   URL format [6].

20.5. Attribute Value encoding rules

   Attribute values, and attribute tags are CASE INSENSITIVE for
   purposes of lexical comparison.

   Attribute values are strings containing any characters with the
   exception of '(', ')', '=', '>', '<', '/', '*', and ',' (the comma)
   except in the case described below where opaque values are encoded.
   These characters may be included using the character value escape
   mechanism described in section 17.1.1.

   While an attribute can take any value, there are three types of
   values which differentiate themselves from general strings:
   Booleans, Integers and Opaque values.

    -  Boolean values are either "TRUE" or "FALSE".  This is the case
       regardless of the language (i.e.  in French or Telugu, Boolean
       TRUE is "TRUE", as well as in English.)  Boolean attributes can
       take only one value.
Top   ToC   RFC2165 - Page 56
    -  Integer values are expressed as a sequence of numbers.  The
       range of allowable values for integers is "-2147483648" to
       "2147483647".  No other form of numeric representation is
       interpreted as such except integers.  For example, hexadecimal
       numbers such as "0x342" are not interpreted as integers, but as
       strings.

    -  Opaque values (i.e.  binary values) are expressed in radix-64
       notation.  The syntax is:

            <opaque-val>    ::=  (<len>:<radix-64-data>)
            <len>           ::=  number of bytes of the original data
            <radix-64-data> ::=  radix-64 encoding of the original data

       <len> is a 16-bit binary number.  Radix-64 encodes every 3 bytes
       of binary data into 4 bytes of ASCII data which is in the range
       of characters which are fully printable and transferable by mail.
       For a formal definition of the Radix-64 format see RFC 1521 [7],
       MIME Part One, Section 5.2 Base64 Content Transfer Encoding, page
       21.

21. Protocol Requirements

   In this section are listed various protocol requirements for User
   Agents, Service Agents, and Directory Agents.

21.1. User Agent Requirements

   A User Agent MAY:

    -  Provide a way for the application to configure the default DA, so
       that it can be used without needing to find it each initially.

    -  Be able to request the address of a DA from DHCP, if configured
       to do so.

    -  Ignore any unauthenticated Service Reply.

    -  Be able to issue requests in any language or character set
       provided that it can switch to the default language and character
       set if the request can not be serviced by DAs and SAs at the
       site.

    -  Require an authentication block in any URL entry returned as
       part of a Service Request, before making use of the advertised
       service.
Top   ToC   RFC2165 - Page 57
   A User Agent SHOULD:

    -  Try to contact DHCP to obtain the address of a DA.

    -  Use a scope in all requests, if possible.

    -  Issue requests to scoped DAs if the UA has been configured with a
       scope.

    -  Listen on the Service Location General Multicast address for
       unsolicited DA Advertisements.  This will increase the set of
       Directory Agents available to it for making requests.  See
       Section 15.2.

    -  Be able to be configured to require an authentication block in
       any received URL entry advertised as belonging to a protected
       scope, before making use of the service.

   If the UA does not listen for DA Advertisements, new DAs will not be
   passively detected.  A UA which does not have a configured DA and has
   not yet discovered one and is not listening for unsolicited DA
   Advertisements will remain ignorant of DAs.  It may then do a DA
   discovery before each query performed or it may simply use multicast
   queries to Service Agents.

   A User Agent MUST:

    -  Be able to unicast requests and receive replies from a DA.
       Transactions should be made reliable by using retransmission of
       the request if the reply does not arrive within a timeout
       interval.

    -  Be able to detect DAs using a Directory Agent Discovery request
       issued when the UA starts up.

    -  Be able to send requests to a multicast address.  Service
       Specific Multicast addresses are computed based on a hash of the
       Service Type.  See Section 3.6.2.

    -  Be able to handle numerous replies after a multicast request.
       The implementation may be configurable so it will either return
       the first reply, all replies until a timeout or keep trying till
       the results converge.

    -  Ignore any unauthenticated Service Reply or Attribute Reply when
       an appropriate IPSec Security Association for that Reply exists.
Top   ToC   RFC2165 - Page 58
    -  Whenever it obtains its IP address from DHCP in the first place,
       also attempt to obtain scope information, and the address of a
       DA, from DHCP.

    -  Use the IP Authentication Header or IP Encapsulating Payload in
       all Service Location messages, whenever an appropriate IPSec
       Security Association exists.

    -  Be able to issue requests using the US-ASCII character set.

    -  If configured to use a protected scope, be able to use
       "md5WithRSAEncryption" [4] to verify the signed data.

21.2. Service Agent Requirements

   A Service Agent MAY be able to:

    -  Get the address of a local Directory Agent by way of DHCP.

    -  Accept requests in non-US-ASCII character encodings.  This is
       encouraged, especially for UNICODE [1] and UTF-8 [24] encodings.

    -  Register services with a DA in non-US-ASCII character encodings.
       This is encouraged, especially for UNICODE [1] and UTF-8 [24]
       encodings.

   A Service Agent SHOULD be able to:

     -  Listen to the service-specific multicast address of the service
       it is advertising.  The incoming requests should be filtered:  If
       the Address Specification of the SA is in the Previous Responders
       Address Specification list, the SA SHOULD NOT respond.
       Otherwise, a response to the multicast query SHOULD be unicast to
       the UA which sent the request.

    -  Listen for and respond to broadcast requests and TCP connection
       requests, to the Service Location port.

    -  Be configurable to calculate authentication blocks and thereby
    be enabled to register in protected scopes.  This requires that the
    service agent be configured to possess the necessary keys to
    calculate the authenticator.

   A Service Agent MUST be able to:

    -  Listen to the Service Location General Multicast address for
       queries (e.g., Service Type Requests).  If the query can be
       replied to by the Service Agent, the Service Agent MUST do so.
Top   ToC   RFC2165 - Page 59
       It MUST check first to make sure it is not on the list of
       'previous responders.'

    -  Listen to the Service Location General Multicast address for
       unsolicited DA Advertisements.  If one is detected, and the DA
       has the right scope, (or has no scope), all services which are
       currently being advertised MUST be registered with the DA (unless
       configured to only use a single DA (see section 22.1), or the DA
       has already been detected, subject to certain rules (see section
       15.2)).

    -  Whenever it obtains its IP address from DHCP in the first place,
       also attempt to obtain scope information, and the address of a
       DA, from DHCP.

    -  Unicast registrations and deregistrations to a DA. Transactions
       should be made reliable by using retransmission of the request if
       the reply does not arrive within a timeout interval.

    -  Be able to detect DAs using a Directory Agent Discovery request
       issued when the SA starts up (unless configured to only use a
       single DA, see section 22.1.)

    -  Use the IP Authentication Header or IP Encapsulating Payload in
       all Service Location messages, whenever an appropriate IPSec
       Security Association exists.

    -  Be able to register service information with a DA using US-ASCII
       character encoding.  It must also be able to reply to requests
       from UAs which use US-ASCII character encoding.

    -  Reregister with a DA before the Lifetime of registered service
       information elapses.

    -  If configured to use a protected scope, be able to use
       "md5WithRSAEncryption" [4] to produce the signed data.

21.3. Directory Agent Requirements

   A Directory Agent MAY:

    -  Accept registrations and requests in non-US-ASCII character
       encodings.  This is encouraged, especially for UNICODE [1] and
       UTF-8 [24] encodings.
Top   ToC   RFC2165 - Page 60
   A Directory Agent SHOULD:

    -  Be able to configure certain scopes as protected scopes, so that
       registrations within those scopes require the calculation of
       cryptographically strong authenticators.  This requires that the
       DA be able to possess the keys needed for the authentication, or
       that the DA be able to acquire a certificate generated by a
       trusted Certificate Authority [23], before completing Service
       Registrations for protected scopes.

   A Directory Agent MUST be able to:

    -  Send an unsolicited DA Advertisements to the Service Location
       General Multicast address on startup and repeat it periodically.
       This reply has an XID which is incremented by one each time.  If
       the DA starts with state, it initializes the XID to 0x0100.  If
       it starts up stateless, it initializes the XID to 0x0000.

    -  Ignore any unauthenticated Service Registration or Service
       Deregistration from an entity with which it maintains a security
       association.

    -  Listen on the Directory Agent Discovery Multicast Address for
       Directory Agent Discovery requests.  Filter these requests if the
       Previous Responder Address Specification list includes the DA's
       Address Specification.

    -  Listen for broadcast requests to the Service Location port.

    -  Listen on the TCP and UDP Service Location Ports for unicast
       requests, registrations and deregistrations and service them.

    -  Provide a way in which scope information can be used to configure
       the Directory Agent.

    -  Expire registrations when the service registration's lifetime
       expires.

    -  When a Directory Agent has been configured with a scope, it MUST
       refuse all requests and registrations which do not have this
       scope.  The DA replies with a SCOPE_NOT_SUPPORTED error.  There
       is one exception:  All DAs MUST respond to DA discovery requests
       which have no scope.

    -  When a Directory Agent has been configured without a scope, it
       MUST accept ALL registrations and requests.
Top   ToC   RFC2165 - Page 61
    -  Ignore any unauthenticated Service Location messages when an
       appropriate IPSec Security Association exists for that request.

    -  Use the IP Authentication and IP Encapsulating Security Payload
       in Service Location messages whenever an appropriate IPSec
       Security Association exists.

    -  Accept requests and registrations in US-ASCII.

    -  If configured with a protected scope, be able to authenticate (at
       least by using "md5WithRSAEncryption" [4]) Service Registrations
       advertising services purporting to belong to such configured
       protected scopes.

22. Configurable Parameters and Default Values

   There are several configuration parameters for Service Location.
   Default values are chosen to allow protocol operation without the
   need for selection of these configuration parameters, but other
   values may be selected by the site administrator.  The configurable
   parameters will allow an implementation of Service Location to be
   more useful in a variety of scenarios.

      Multicast vs.  Broadcast
               All Service Location entities must use multicast by
               default.  The ability to use broadcast messages must be
               configurable for UAs and SAs.  Broadcast messages are to
               be used in environments where not all Service Location
               entities have hardware or software which supports
               multicast.

      Multicast Radius
               Multicast requests should be sent to all subnets in a
               site.  The default multicast radius for a site is 32.
               This value must be configurable.  The value for the
               site's multicast TTL may be obtained from DHCP using an
               option which is currently unassigned.

      Directory Agent Address
               The Directory Agent address discovery mechanism must be
               configurable.  There are three possibilities for this
               configuration:  A default address, no default address and
               the use of DHCP to locate a DA as described in section
               15.2.  The default value should be use of DHCP, with "no
               default address" used if DHCP does not respond.  In this
               case the UA or SA must do a Directory Agent Discovery
               query.
Top   ToC   RFC2165 - Page 62
      Directory Agent Scope Assignment
               The scope or scopes of a DA must be configurable.  The
               default value for a DA is to have no scope if not
               otherwise configured.

      Path MTU
               The default path MTU is assumed to be 1400.  This value
               may be too large for the infrastructure of some sites.
               For this reason this value MUST be configurable for all
               SAs and DAs.

      Keys for Protected Scopes

               If the local administration designates certain scopes as
               "protected scopes", the agents making use of those scopes
               have to be able to acquire keys to authenticate data sent
               by services along with their advertised URLs for services
               within the protected scope.  For instance, service agents
               would use a private key to produce authentication data.
               By default, service agents use "md5WithRSAEncryption" [4]
               to produce the signed data, to be be included with
               service registrations and deregistrations (see appendix
               B, 4.3).  This authentication data could be verified by
               user agents and directory agents that possess the
               corresponding public key.

22.1. Service Agent:  Use Predefined Directory Agent(s)

   A Service Agent's default configuration is to do passive and active
   DA discovery and to register with all DAs which are properly scoped.

   A Service Agent SHOULD be configurable to allow a special mode of
   operation:  They will use only preconfigured DAs.  This means they
   will *NOT* actively or passively detect DAs.

   If a Service Agent is configured this way, knowledge of the DA must
   come through another channel, either static configuration or by the
   use of DHCP.

   The availability of the Service information will not be consistent
   between DAs.  The mechanisms which achieve eventual consistency
   between DAs are ignored by the SA, so their service information will
   not be distributed.  This leaves the SA open to failure if the DA
   they are configured to use fails.
Top   ToC   RFC2165 - Page 63
22.2. Time Out Intervals

   These values should be configurable in case the site deploying
   Service Location has special requirements (such as very slow links.)

   Interval name       Section Default Value Meaning
   -----------------   ------- ------------- -----------------------
   CONFIG_INTERVAL_0   4.1     1 minute      Cache replies by XID.
   CONFIG_INTERVAL_1   4.4     10800 seconds registration Lifetime,
                               (ie.  3 hours)after which ad expires
   CONFIG_INTERVAL_2   5       each second,  Retry multicast query
                               backing off   until no new values
                               gradually     arrive.
   CONFIG_INTERVAL_3   5       15 seconds    Max time to wait for a
                                             complete multicast query
                                             response (all values.)
   CONFIG_INTERVAL_4   9       3 seconds     Wait to register on
                                             reboot.
   CONFIG_INTERVAL_5   5.2     3 seconds     Retransmit DA discovery,
                                             try it 3 times.
   CONFIG_INTERVAL_6   5.2     5 seconds     Give up on requests sent
                                             to a DA.
   CONFIG_INTERVAL_7   5.2     15 seconds    Give up on DA discovery
   CONFIG_INTERVAL_8   5.1     15 seconds    Give up on requests
                                             sent to SAs.
   CONFIG_INTERVAL_9   15.2    3 hours       DA Heartbeat, so that SAs
                                             passively detect new DAs.
   CONFIG_INTERVAL_10  15.2    1-3 seconds   Wait to register services
                                             on passive DA discovery.
   CONFIG_INTERVAL_11  9       1-3 seconds   Wait to register services
                                             on active DA discovery.
   CONFIG_INTERVAL_12  18.1    5 minutes     DAs and SAs close idle
                                             connections.

   A note on CONFIG_INTERVAL_9:  While it might seem advantageous to
   have frequent heartbeats, this poses a significant risk of generating
   a lot of overhead traffic.  This value should be kept high to prevent
   routine protocol operations from using any significant bandwidth.

23. Non-configurable Parameters

   IP Port number for unicast requests to Directory Agents:

         UDP and TCP Port Number:                          427
Top   ToC   RFC2165 - Page 64
   Multicast Addresses

         Service Location General Multicast Address:       224.0.1.22
         Directory Agent Discovery Multicast Address:      224.0.1.35

   A range of 1024 contiguous multicast addresses for use as Service
   Specific Discovery Multicast Addresses will be assigned by IANA.

   Error Codes:

         No Error                   0
         LANGUAGE_NOT_SUPPORTED     1
         PROTOCOL_PARSE_ERROR       2
         INVALID_REGISTRATION       3
         SCOPE_NOT_SUPPORTED        4
         CHARSET_NOT_UNDERSTOOD     5
         AUTHENTICATION_ABSENT      6
         AUTHENTICATION_FAILED      7


24. Acknowledgments

   This protocol owes some of the original ideas to other service
   location protocols found in many other networking protocols.  Leo
   McLaughlin and Mike Ritter (Metricom) provided much input into early
   version of this document.  Thanks also to Steve Deering (Xerox) for
   providing his insight into distributed multicast protocols.  Harry
   Harjono and Charlie Perkins supplied the basis for the URL based wire
   protocol in their Resource Discovery Protocol.  Thanks also to
   Peerlogic, Inc.  for supporting this work.  Lastly, thanks to Jeff
   Schiller for his help in shaping the security architecture specified
   in this document.
Top   ToC   RFC2165 - Page 65
A. Appendix:  Technical contents of ISO 639:1988 (E/F): "Code for the
   representation of names of languages"

   Two-letter lower-case symbols are used.  The Registration Authority
   for ISO 639 [14] is Infoterm, Osterreiches Normungsinstitut (ON),
   Postfach 130, A-1021 Vienna, Austria.  Contains additions from ISO
   639/RA Newsletter No.1/1989. See also RFC 1766.

    aa Afar               ga Irish               mg Malagasy
    ab Abkhazian          gd Scots Gaelic        mi Maori
    af Afrikaans          gl Galician            mk Macedonian
    am Amharic            gn Guarani             ml Malayalam
    ar Arabic             gu Gujarati            mn Mongolian
    as Assamese                                  mo Moldavian
    ay Aymara             ha Hausa               mr Marathi
    az Azerbaijani        he Hebrew              ms Malay
                          hi Hindi               mt Maltese
    ba Bashkir            hr Croatian            my Burmese
    be Byelorussian       hu Hungarian
    bg Bulgarian          hy Armenian            na Nauru
    bh Bihari                                    ne Nepali
    bi Bislama            ia Interlingua         nl Dutch
    bn Bengali; Bangla    in Indonesian          no Norwegian
    bo Tibetan            ie Interlingue
    br Breton             ik Inupiak             oc Occitan
                          is Icelandic           om (Afan) Oromo
    ca Catalan            it Italian             or Oriya
    co Corsican           ja Japanese
    cs Czech              jw Javanese            pa Punjabi
    cy Welsh                                     pl Polish
                          ka Georgian            ps Pashto, Pushto
    da Danish             kk Kazakh              pt Portuguese
    de German             kl Greenlandic
    dz Bhutani            km Cambodian           qu Quechua
                          rw Kinyarwanda
    el Greek              kn Kannada             rm Rhaeto-Romance
    en English            ko Korean              rn Kirundi
    eo Esperanto          ks Kashmiri            ro Romanian
    es Spanish            ku Kurdish             ru Russian
    et Estonian           ky Kirghiz
    eu Basque
                          la Latin
    fa Persian            ln Lingala
    fi Finnish            lo Laothian
    fj Fiji               lt Lithuanian
    fo Faeroese           lv Latvian, Lettish
    fr French
    fy Frisian
Top   ToC   RFC2165 - Page 66
    sa Sanskrit           ta Tamil               ug Uigar
    sd Sindhi             te Telugu              uk Ukrainian
    sg Sangro             tg Tajik               ur Urdu
    sh Serbo-Croatian     th Thai                uz Uzbek
    si Singhalese         ti Tigrinya
    sk Slovak             tk Turkmen             vi Vietnamese
    sl Slovenian          tl Tagalog             vo Volapuk
    sm Samoan             tn Setswana
    sn Shona              to Tonga               wo Wolof
    so Somali             tr Turkish
    sq Albanian           ts Tsonga              xh Xhosa
    sr Serbian            tt Tatar
    ss Siswati            tw Twi                 yi Yiddish
    st Sesotho                                   yo Yoruba
    su Sundanese
    sv Swedish                                   za Zhuang
    sw Swahili                                   zh Chinese
                                                 zu Zulu


B. SLP Certificates

   Certificates may be used in SLP in order to distribute the public
   keys of trusted protected scopes.  Assuming public keys, this
   appendix discusses the use of such certificates in the Service
   Location Protocol.

   Possession of the private key of a protected scope is equivalent to
   being a trusted SA. The trustworthiness of the protected scope
   depends upon all of these private keys being held by trusted hosts,
   and used only for legitimate service registrations and
   deregistrations.

   With access to the proper Certificate Authority (CA), DAs and UAs do
   not need (in advance) hold public keys which correspond to these
   protected scopes.  They do require the public key of the CA. The CA
   produces certificates using its unique private key.  This private key
   is not shared with any other system, and must remain secure.  The
   certificates declare that a given protected scope has a given public
   key, as well as the expiration date of the certificate.

   The ASCII (mail-safe) string format for the certificate is the
   following list of tag and value pairs:

      "certificate-alg=" 1*ASN1CHAR       CRLF
      "scope-charset="   1*DIGIT          CRLF
      "scope="           1*RADIX-64-CHAR  CRLF
      "timestamp="       16HEXDIGIT       CRLF
Top   ToC   RFC2165 - Page 67
      "public-key="      1*RADIX-64-CHAR  CRLF
      "cert-digest="     1*RADIX-64-CHAR  CRLF

      ASN1CHAR          = DIGIT | '.'
      HEXDIGIT          = DIGIT | 'a'..'f' | 'A'..'F'
      RADIX-64-CHAR     = DIGIT | 'a'..'z' | 'A'..'Z' | '+' | '/' | '='

   The radix-64 notation is described in RFC 1521 [7].  Spaces are
   ignored in the computation of the binary value corresponding to a
   Radix-64 string.  If the value for scope, public-key or cert-digest
   is greater than 72 characters, the Radix-64 notation may be broken up
   on to separate lines.  The continuation lines must be preceded by one
   or more spaces.  Only the tags listed above may start in the first
   column of the certificate string.  This removes ambiguity in parsing
   the Radix-64 values (since the tags consist of legal Radix-64
   values.)

   The certificate-alg is the ASN.1 string for the Object Identifier
   value of the algorithm used to produce the "cert-digest".  The
   scope-charset is a decimal representation of the MIBEnum value for
   the character set in which the scope is represented.

   The radix-64 encoding of the scope string will allow the ASCII
   rendering of a scope string any character set.

   The 8 byte NTP format timestamp is represented as 16 hex digits.
   This timestamp is the time at which the certificate will expire.

   The format for the public key will depend on the type of cryptosystem
   used, which is identified by the certificate-alg.  When the CA
   generated the certificate holding the public key being obtained, it
   used the message digest algorithm identified by certificate-alg to
   calculate a digest D on the string encoding of the certificate,
   excepting the cert-digest.  The CA then encrypted this value using
   the CA's private key to produce the cert-digest, which is included in
   the certificate.

   The CA generates the certificate off-line.  The mechanism to
   distibute certificates is not specified in the Service Location
   Protocol, but may be in the future.  The CA specifies the algorithms
   to use for message digest and public key decryption.  The DA or SA
   need only obtain the certificate, have a preconfigured public key for
   the CA and support the algorithm specified in the certificate-alg in
   order to obtain certified new public keys for protected scopes.

   The DA or UA may confirm the certificate by calculating the message
   digest D, using the message digest algorithm identified by the
   certificate-alg.  The input to the message digest algorithm is the
Top   ToC   RFC2165 - Page 68
   string encoding of the certificate, excepting the cert-digest.  The
   cert-digest is decrypted using the CA's public key to produce D'. If
   D is the same as D', the certificate is legitimate.  The public-key
   for the protected scope may be used until the expiration date
   indicated by the certificate timestamp.

   The certificate may be distributed along untrusted channels, such as
   email or through file transfer, as it must be verified anyhow.  The
   CA's public key must be delivered using a trusted channel.

C. Example of deploying SLP security using MD5 and RSA

   In our site, we have a protected scope "CONTROLLED".  We generate a
   private key - public key pair for the scope, using RSA. The private
   key is maintained on a secret key ring by all SAs in the protected
   scope.  The public key is available to all DAs which support the
   protected scope and to all UAs which will use it.

   In order to register or deregister a URL, the data required to be
   authenticated (as described in section 4.3) is digestified using MD5
   [22] to create a digital signature, then encrypted by RSA with the
   protected scope's private key.  The output of RSA is used in the
    authenticator data field of the authenticator block.

   The DA or UA discovers the appropriate method for verifying the
   authentication by looking inside the authentication block.  Suppose
   that the "md5WithRSAEncryption" [4] algorithm has to be used to
   verify the signed data.  The DA or UA calculates the message digest
   of the URL Entry by using md5, exactly as the SA did.  The
   authenticator block is decrypted using the public key for the
   "CONTROLLED" scope, which is stored in the public key ring of the UA
   or DA under the name "CONTROLLED".  If the digest calculated by the
   UA or DA matches that of the SA, the URL Entry has been validated.

D. Example of use of SLP Certificates by mobile nodes

   Say a mobile node needs to make use of protected scopes.  The mobile
   node is first preconfigured by adding a single public key to its
   public key ring:  We will call it the CA-Key.  This key will be used
   to obtain SLP certificates in the format described in Appendix B.
   The corresponding private key will be used by the CA to create the
   certificates in the necessary format.

   The CA might be operated by a system administrator using a computer
   which is not connected to any networks.  The certificate's duration
   will depend on the policy of the site.  The duration, scope, and
   public key for the protected scope, are used as input to 'md5sum'.
   This sum is then encrypted with RSA using the CA's private key.  The
Top   ToC   RFC2165 - Page 69
   radix 64 encoding of this is added to the mail-safe string based
   certificate encoding defined in Appendix B.

   The certificate, say for the protected scope "CONTROLLED" could be
   made available to the mobile node.  For example, it might be on a web
   page.  The mobile node could then process the certificate in order to
   obtain the public key for the CONTROLLED scope.  There is still no
   reason to *trust* this key is really the one to use (as in Appendix
   C).  To trust it, calculate the md5 checksum of the ascii encoded
   certificate, excluding the cert-digest.  Next, decrypt the cert-
   digest using the CA's public key and RSA. If the cert-digest matches
   the output of MD5, the certificate may be trusted (until it expires).

   The mobile node requires only one key (CA-key) in order to obtain
   others dynamically and make use of protected scopes.  Notice that we
   do not define any method for access control by arbitrary UAs to SAs
   in protected scopes.

E. Appendix:  For Further Reading

   Three related resource discovery protocols are NBP and ZIP which are
   part of the AppleTalk protocol family [12], the Legato Resource
   Administration Platform [25], and the Xerox Clearinghouse system
   [20].  Domain names and representation of addresses are used
   extensively in the Service Location Protocol.  The references for
   these are RFCs 1034 and 1035 [17, 18].  Example of a discovery
   protocol for routers include Router Discovery [10] and Neighbor
   Discovery [19].
Top   ToC   RFC2165 - Page 70
References

   [1] Unicode Technical Report #4.  The unicode standard, version 1.1
       (volumes 1 and 2).  Technical Report (ISBN 0-201-56788-1) and
       (ISBN 0-201-60845-6), Unicode Consortium, 1994.

   [2] Alexander, S. and R. Droms.  DHCP Options and BOOTP Vendor
       Extensions.  RFC 2131, March 1997.

   [3] Atkinson, R.  IP Encapsulating Security Payload.  RFC 1827,
       August 1995.

   [4] Balenson, D.  Privacy Enhancement for Internet Electronic
       Mail:  Part III: Algorithms, Modes, and Identifiers.  RFC 1423,
       February 1993.

   [5] Berners-Lee, T. and D. Connolly.  Hypertext Markup Language -
       2.0.  RFC 1866, November 1995.

   [6] Berners-Lee, T., L. Masinter, and M. McCahill.  Uniform Resource
       Locators (URL).  RFC 1738, December 1994.

   [7] Borenstein, N. and N. Freed.  MIME (Multipurpose Internet Mail
       Extensions) Part One:  Mechanisms for Specifying and Describing
       the Format of Internet Message Bodies.  RFC 2045, November 1996.

   [8] Bradner, Scott.  Key words for use in RFCs to Indicate
       Requirement Levels. BCP 14, RFC 2119, March 1997.

   [9] CCITT.  Specification of the Abstract Syntax Notation One
       (ASN.1).  Recommendation X.208, 1988.

   [10] Deering, Stephen E., editor.  ICMP Router Discovery Messages.
        RFC 1256, September 1991.

   [11] Droms, Ralph.  Dynamic Host Configuration Protocol.  RFC 2131,
        March 1997.

   [12] Gursharan, S., R. Andrews, and A. Oppenheimer.  Inside
        AppleTalk. Addison-Wesley, 1990.

   [13] Guttman, E.  The service:  URL scheme, November 1996.
        Work In Progress.

   [14] Geneva ISO.  Code for the representation of names of languages.
        ISO 639:1988 (E/F), 1988.
Top   ToC   RFC2165 - Page 71
   [15] ISO 8879, Geneva.  Information Processing -- Text and Office
        Systems - Standard Generalized Markup Language (SGML).
        <URL:http://www.iso.ch/cate/d16387.html>, 1986.

   [16] Mills, D.  Simple Network Time Protocol (SNTP) Version 4 for
        IPv4, IPv6 and OSI.  RFC 2030, October 1996.

   [17] Mockapetris, P.  Domain Names - Concepts and Facilities. STD 13,
        RFC 1034, November 1987.

   [18] Mockapetris, P.  DOMAIN NAMES - IMPLEMENTATION AND
        SPECIFICATION.  STD 13, RFC 1035, November 1987.

   [19] Narten, T., E. Nordmark, and W. Simpson.  Neighbor Discovery for
        IP version 6 (IPv6).  RFC 1970, August 1996.

   [20] Oppen, D. and Y. Dalal.  The clearinghouse:  A decentralized
        agent for locating named objects in a distributed environment.
        Technical Report Tech. Rep. OPD-78103, Xerox Office Products
        Division, 1981.

   [21] Perkins, C.  DHCP Options for Service Location Protocol, August
        1996. Work In Progress.

   [22] Rivest, Ronald.  The MD5 Message-Digest Algorithm.  RFC 1321,
        April 1992.

   [23] Schneier, Bruce.  Applied Cryptography:  Protocols, Algorithms,
        and Source Code in C.  John Wiley, New York, NY, USA, 1994.

   [24] X/Open Preliminary Specification.  File System Safe UCS
        Transformation Format (FSS_UTF).  Technical Report Document
        Number:  P316, X/Open Company Ltd., 1994.

   [25] Legato Systems.  The Legato Resource Administration Platform.
        Legato Systems, 1991.
Top   ToC   RFC2165 - Page 72
Authors' Addresses

   Questions about this memo can be directed to:

   John Veizades                       Erik Guttman
   @Home Network                       Sun Microsystems
   385 Ravendale Dr.                   Gaisbergstr. 6
   Mountain View, CA 94043             69115 Heidelberg Germany

   Phone: +1 415 944 7332              Phone: +1 415 336 6697
   Fax:   +1 415 944 8500

   Email: veizades@home.com            Email: Erik.Guttman@eng.sun.com

   Charles E. Perkins                  Scott Kaplan
   Sun Microsystems
   2550 Garcia Avenue                  346 Fair Oaks St.
   Mountain View, CA  94043            San Francisco, CA 94110

   Phone: +1 415 336 7153              Phone: +1 415 285 4526
   Fax:   +1 415 336 0670

   EMail: cperkins@Corp.sun.com        Email: scott@catch22.com