The Service Location Protocol has an 'escape mechanism' which is
consistent with HTTP 2.0 [5] and SGML [15]. If the character
sequence "&#" is followed by one or more digits, followed by a
semicolon ';' the entire sequence is interpreted as a single
character. The digits are interpreted as a decimal value in the
character set of the request, as specified by the header. Thus, in
US-ASCII , would be interpreted as a comma. Substitution of
these escape strings must be done in all <attr-list> and strings
present in SrvReq and AttrRqst messages. Only numerical character
references are accepted, not 'Entity References,' as defined in HTML.
These escape values should only be used to provide a mechanism for
including reserved characters in attribute tag and value strings.
The interpretation of these escape values is different than in HTML
in one respect: In HTML the escape values are considered to be in
the ISO Latin-1 character set. In Service Location they are
interpreted in the character set defined in the header of the
message.
This escape mechanism allows characters like commas to be included in
attribute tags and values, which would otherwise be illegal as the
comma is a protocol delimiter.
Attribute tags and values of different languages are considered to be
mutually unintelligible. A query in one language SHOULD use service
information registered in that language.
17.2. Language-Independent Strings
Some strings, such as Service Type names, have standard definitions.
These strings should be considered as tokens and not as words in a
language to be translated.
Reserved String Section xDefinition
--------------- ------- --------------------------------------
SCOPE 3, 15 Used to limit the matching of requests.
SERVICE 6, 9 The URL scheme of all Service Location
information registered with a DA or
returned from a Service Request.
<srvtype> 20.2.1 Used in all service registrations
and replies.
domain names 20.4 A fully qualified domain name, used
in registrations and replies.
IANA 3.3 The default naming authority.
LOCAL 16 Reserved.
REMOTE 16 Reserved.
TRUE 20.5 Boolean true.
FALSE 20.5 Boolean false.
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 RFC1738 [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 RFC1521 [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 RFC1766.
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 RFC1521 [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. RFC2131, March 1997.
[3] Atkinson, R. IP Encapsulating Security Payload. RFC1827,
August 1995.
[4] Balenson, D. Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers. RFC1423,
February 1993.
[5] Berners-Lee, T. and D. Connolly. Hypertext Markup Language -
2.0. RFC1866, November 1995.
[6] Berners-Lee, T., L. Masinter, and M. McCahill. Uniform Resource
Locators (URL). RFC1738, 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. RFC2045, November 1996.
[8] Bradner, Scott. Key words for use in RFCs to Indicate
Requirement Levels. BCP 14, RFC2119, 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.
RFC1256, September 1991.
[11] Droms, Ralph. Dynamic Host Configuration Protocol. RFC2131,
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. RFC2030, October 1996.
[17] Mockapetris, P. Domain Names - Concepts and Facilities. STD 13,
RFC1034, November 1987.
[18] Mockapetris, P. DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION. STD 13, RFC1035, November 1987.
[19] Narten, T., E. Nordmark, and W. Simpson. Neighbor Discovery for
IP version 6 (IPv6). RFC1970, 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. RFC1321,
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