1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
# Names of submitters: Jonathan Wood <jonathan.wood@eng.sun.com>
# Roberto Tam <roberto.tam@eng.sun.com>
# Language of service template: en
# Security Considerations:
# This LDAP service type inherits the security considerations from the
# naming-directory service type [4], the SLP specification [1].
# Implementors should also be aware of the security considerations
# discussed in [5].
#--------------------------------------------------------------------------
# This document describes a template providing a service: URL and
# attributes useful for dynamically discovering LDAP servers; this type
# can be used with SLP [1]. Service templates and service: schemes are
# defined in [2].
#
# LDAP (Lightweight Directory Access Protocol) [3] directories are
# now being used as repositories for UNIX-style system information.
# As such, LDAP service is suitable to be included in the naming-
# directory class. This type is intended to be used as a concrete
# portion of the abstract naming-directory type defined in [4]. The
# LDAP type includes all attributes from the naming-directory abstract
# type, and defines new attributes pertaining to security and access
# protocols.
#
# For usage examples for non-LDAP specific scenarios, refer to [4].
# Differentiating Servers by Authentication Mechanisms
# Possible means of authenticating LDAP transactions are defined
# in [5]. In order to agree on a particular authentication mechanism,
# a client and server might need to go through a number of iterations
# and levels of negotiation. Currently there are three levels of
# mechanisms: The first level consists of the basic mechanisms,
# anonymous, simple, and TLS. The second layer consists of the SASL
# negotiation layer [6]. The third layer consists of GSSAPI [7]
# mechanisms, and possible the GSS-SPNEGO negotiation sequence [8].
# Thus it is possible that a client wishing to use the Kerberos V5
# GSSAPI mechanism may need to negotiate its way through SASL and
# GSS-SPNEGO before coming to an agreement with the server.
#
# Since LDAP clients are already aware of what mechanisms they have
# been configured to use when connecting to an LDAP server, the
# attributes in this template have been designed to allow clients to
# optimize both their search for servers and the following negotiation
# sequence for authentication mechanisms. Clients may specify as
# little or as much of their desired negotiation path. For example,
# all of the following SLP [1] search filters are valid:
#
# (security=sasl)
#
# (&(security=sasl)(|(sasl-mechs=cram-md5)(sasl-mechs=external)))
#
# (&(security=sasl)(sasl-mechs=GSSAPI)(gss-mechs=1.3.5.1.5.2))
#
# The more fully a client specifies the negotiation path, the greater
# the likelihood that the client will discover a server which
# supports the same mechanisms as the client. If a server does not
# support the required mechanisms, clients will need to move on to
# other discovered servers, and repeat the negotiation process. This
# can be a costly process. Additionally, clients should be able to
# optimize the resulting negotiation, bypassing mechanisms which are
# not acceptable to one of the parties.
#
# The allowable values for the "security" attribute follows those
# defined in [5].
#
# The allowable values for the "sasl-mechs" and "gss-mechs"
# attributes are meant to be fluid, following the decisions of their
# respective working groups.
#
# [1] E. Guttman, C. Perkins, J. Veizades, M. Day. Service Location
# Protocol. RFC 2608, April 1999
#
# [2] E. Guttman, C. Perkins, J. Kempf, Service Templates and service:
# Schemes. RFC 2609, February 1999
#
# [3] W. Yeong, T. Howes, S. Kille, Lightweight Directory Access
# Protocol, RFC 1777 March 1995
#
# [4] J. Wood, R. Tam, The Naming and Directory Service Abstract Type.
# draft-ietf-svrloc-naming-directory-01.txt, June 1999 (work in
# progress)
#
# [5] M. Wahl, H. Alvestrand, J. Hodges, RL Morgan. Authentication
# Methods for LDAP, draft-ietf-ldapext-authmeth-04.txt, November
# 1998 (work in progress)
template-type=naming-directory:ldap
template-version=1.0
template-description=
This is a concrete type; the abstract type for this service
is naming-directory (described in the 'naming-directory' service
type template). This type is used by LDAP servers to advertise their
services and LDAP clients which wish to discover LDAP servers.
template-url=syntax=
url-path = ldap URL as defined in RFC 2255
security=string M
# Security mechanisms supported by this server. Permitted values
# are drawn from draft-ietf-ldapext-authmeth-03 (Authentication
# Methods for LDAP). If SASL is supported, clients may further
# differentiate servers with the sasl-mechs attribute.
anonymous,simple,tls,sasl
sasl-mechs=string M
# SASL mechanisms supported by this server. If the GSSAPI or GSS-SPNEGO
# mechanisms are supported, clients may further differentiate servers
# with the gss-mechs attribute. SASL mechanisms are registered with
# IANA; legal values of this attribute are the mechanism keywords
# registered with IANA. SASL is defined in RFC 2222.
gss-mechs=string M
# GSSAPI mechanisms supported by this server. The mechanisms are
# named by their object identifiers (OIDs). GSSAPI is defined
# in RFC 2078, and GSS-SPNEGO is defined in RFC 2478.
qop= string
# quality of protection. The refers to how strongly messages are
# protected. There are three possibilities: none, integrity
# (meaning that the integrity and endpoints of the message can
# be guaranteed), and privacy (meaning that the message is
# encrypted).
none,integrity,privacy
transport= string
# the transport used to communicate with this server. Possible
# values are connection-oriented (cots) and connectionless
# (clts).
cots,clts
version= string M
# Which version(s) of LDAP this server supports. "v3" corresponds to
# the protocol as defined by RFC 2251, and "v2" corresponds to the
# protocol as defined by RFC 1777.
v2,v3
extensions= string M
# This is an open-ended attribute intended to contain any standard or
# non-standard (i.e. vendor-specific) extensions this server supports.
|
