RFC 2165
Service Location Protocol
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.
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.
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
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
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.
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.
- 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.
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.
- 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.
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.
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.
- 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.
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.
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
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.
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
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
"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
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
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].
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.
[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.
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