1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc4752.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,563 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                   A. Melnikov, Ed.
    1.11 +Request for Comments: 4752                                         Isode
    1.12 +Obsoletes: 2222                                            November 2006
    1.13 +Category: Standards Track
    1.14 +
    1.15 +
    1.16 +                       The Kerberos V5 ("GSSAPI")
    1.17 +       Simple Authentication and Security Layer (SASL) Mechanism
    1.18 +
    1.19 +Status of This Memo
    1.20 +
    1.21 +   This document specifies an Internet standards track protocol for the
    1.22 +   Internet community, and requests discussion and suggestions for
    1.23 +   improvements.  Please refer to the current edition of the "Internet
    1.24 +   Official Protocol Standards" (STD 1) for the standardization state
    1.25 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.26 +
    1.27 +Copyright Notice
    1.28 +
    1.29 +   Copyright (C) The IETF Trust (2006).
    1.30 +
    1.31 +Abstract
    1.32 +
    1.33 +   The Simple Authentication and Security Layer (SASL) is a framework
    1.34 +   for adding authentication support to connection-based protocols.
    1.35 +   This document describes the method for using the Generic Security
    1.36 +   Service Application Program Interface (GSS-API) Kerberos V5 in the
    1.37 +   SASL.
    1.38 +
    1.39 +   This document replaces Section 7.2 of RFC 2222, the definition of the
    1.40 +   "GSSAPI" SASL mechanism.  This document, together with RFC 4422,
    1.41 +   obsoletes RFC 2222.
    1.42 +
    1.43 +
    1.44 +
    1.45 +
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Melnikov                    Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 4752                 SASL GSSAPI Mechanism             November 2006
    1.64 +
    1.65 +
    1.66 +Table of Contents
    1.67 +
    1.68 +   1. Introduction ....................................................2
    1.69 +      1.1. Relationship to Other Documents ............................2
    1.70 +   2. Conventions Used in This Document ...............................2
    1.71 +   3. Kerberos V5 GSS-API Mechanism ...................................2
    1.72 +      3.1. Client Side of Authentication Protocol Exchange ............3
    1.73 +      3.2. Server Side of Authentication Protocol Exchange ............4
    1.74 +      3.3. Security Layer .............................................6
    1.75 +   4. IANA Considerations .............................................7
    1.76 +   5. Security Considerations .........................................7
    1.77 +   6. Acknowledgements ................................................8
    1.78 +   7. Changes since RFC 2222 ..........................................8
    1.79 +   8. References ......................................................8
    1.80 +      8.1. Normative References .......................................8
    1.81 +      8.2. Informative References .....................................9
    1.82 +
    1.83 +1.  Introduction
    1.84 +
    1.85 +   This specification documents currently deployed Simple Authentication
    1.86 +   and Security Layer (SASL [SASL]) mechanism supporting the Kerberos V5
    1.87 +   [KERBEROS] Generic Security Service Application Program Interface
    1.88 +   ([GSS-API]) mechanism [RFC4121].  The authentication sequence is
    1.89 +   described in Section 3.  Note that the described authentication
    1.90 +   sequence has known limitations, in particular, it lacks channel
    1.91 +   bindings and the number of round-trips required to complete
    1.92 +   authentication exchange is not minimal.  SASL WG is working on a
    1.93 +   separate document that should address these limitations.
    1.94 +
    1.95 +1.1.  Relationship to Other Documents
    1.96 +
    1.97 +   This document, together with RFC 4422, obsoletes RFC 2222 in its
    1.98 +   entirety.  This document replaces Section 7.2 of RFC 2222.  The
    1.99 +   remainder is obsoleted as detailed in Section 1.2 of RFC 4422.
   1.100 +
   1.101 +2.  Conventions Used in This Document
   1.102 +
   1.103 +   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   1.104 +   in this document are to be interpreted as defined in "Key words for
   1.105 +   use in RFCs to Indicate Requirement Levels" [KEYWORDS].
   1.106 +
   1.107 +3.  Kerberos V5 GSS-API Mechanism
   1.108 +
   1.109 +   The SASL mechanism name for the Kerberos V5 GSS-API mechanism
   1.110 +   [RFC4121] is "GSSAPI".  Though known as the SASL GSSAPI mechanism,
   1.111 +   the mechanism is specifically tied to Kerberos V5 and GSS-API's
   1.112 +   Kerberos V5 mechanism.
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Melnikov                    Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 4752                 SASL GSSAPI Mechanism             November 2006
   1.120 +
   1.121 +
   1.122 +   The GSSAPI SASL mechanism is a "client goes first" SASL mechanism;
   1.123 +   i.e., it starts with the client sending a "response" created as
   1.124 +   described in the following section.
   1.125 +
   1.126 +   The implementation MAY set any GSS-API flags or arguments not
   1.127 +   mentioned in this specification as is necessary for the
   1.128 +   implementation to enforce its security policy.
   1.129 +
   1.130 +   Note that major status codes returned by GSS_Init_sec_context() or
   1.131 +   GSS_Accept_sec_context() other than GSS_S_COMPLETE or
   1.132 +   GSS_S_CONTINUE_NEEDED cause authentication failure.  Major status
   1.133 +   codes returned by GSS_Unwrap() other than GSS_S_COMPLETE (without any
   1.134 +   additional supplementary status codes) cause authentication and/or
   1.135 +   security layer failure.
   1.136 +
   1.137 +3.1.  Client Side of Authentication Protocol Exchange
   1.138 +
   1.139 +   The client calls GSS_Init_sec_context, passing in
   1.140 +   input_context_handle of 0 (initially), mech_type of the Kerberos V5
   1.141 +   GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name
   1.142 +   equal to output_name from GSS_Import_Name called with input_name_type
   1.143 +   of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
   1.144 +   "service@hostname" where "service" is the service name specified in
   1.145 +   the protocol's profile, and "hostname" is the fully qualified host
   1.146 +   name of the server.  When calling the GSS_Init_sec_context, the
   1.147 +   client MUST pass the integ_req_flag of TRUE (**).  If the client will
   1.148 +   be requesting a security layer, it MUST also supply to the
   1.149 +   GSS_Init_sec_context a mutual_req_flag of TRUE, and a
   1.150 +   sequence_req_flag of TRUE.  If the client will be requesting a
   1.151 +   security layer providing confidentiality protection, it MUST also
   1.152 +   supply to the GSS_Init_sec_context a conf_req_flag of TRUE.  The
   1.153 +   client then responds with the resulting output_token.  If
   1.154 +   GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
   1.155 +   should expect the server to issue a token in a subsequent challenge.
   1.156 +   The client must pass the token to another call to
   1.157 +   GSS_Init_sec_context, repeating the actions in this paragraph.
   1.158 +
   1.159 +   (*) Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE
   1.160 +   to import servers' acceptor names, but only when they have a priori
   1.161 +   knowledge that the servers support alternate name types.  Otherwise
   1.162 +   clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor
   1.163 +   names.
   1.164 +
   1.165 +   (**) Note that RFC 2222 [RFC2222] implementations will not work with
   1.166 +   GSS-API implementations that require integ_req_flag to be true.  No
   1.167 +   implementations of RFC 1964 [KRB5GSS] or RFC 4121 [RFC4121] that
   1.168 +   require integ_req_flag to be true are believed to exist and it is
   1.169 +   expected that any future update to [RFC4121] will require that
   1.170 +
   1.171 +
   1.172 +
   1.173 +Melnikov                    Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 4752                 SASL GSSAPI Mechanism             November 2006
   1.176 +
   1.177 +
   1.178 +   integrity be available even in not explicitly requested by the
   1.179 +   application.
   1.180 +
   1.181 +   When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines
   1.182 +   the context to ensure that it provides a level of protection
   1.183 +   permitted by the client's security policy.  In particular, if the
   1.184 +   integ_avail flag is not set in the context, then no security layer
   1.185 +   can be offered or accepted.
   1.186 +
   1.187 +   If the conf_avail flag is not set in the context, then no security
   1.188 +   layer with confidentiality can be offered or accepted.  If the
   1.189 +   context is acceptable, the client takes the following actions: If the
   1.190 +   last call to GSS_Init_sec_context returned an output_token, then the
   1.191 +   client responds with the output_token, otherwise the client responds
   1.192 +   with no data.  The client should then expect the server to issue a
   1.193 +   token in a subsequent challenge.  The client passes this token to
   1.194 +   GSS_Unwrap and interprets the first octet of resulting cleartext as a
   1.195 +   bit-mask specifying the security layers supported by the server and
   1.196 +   the second through fourth octets as the maximum size output_message
   1.197 +   the server is able to receive (in network byte order).  If the
   1.198 +   resulting cleartext is not 4 octets long, the client fails the
   1.199 +   negotiation.  The client verifies that the server maximum buffer is 0
   1.200 +   if the server does not advertise support for any security layer.
   1.201 +
   1.202 +   The client then constructs data, with the first octet containing the
   1.203 +   bit-mask specifying the selected security layer, the second through
   1.204 +   fourth octets containing in network byte order the maximum size
   1.205 +   output_message the client is able to receive (which MUST be 0 if the
   1.206 +   client does not support any security layer), and the remaining octets
   1.207 +   containing the UTF-8 [UTF8] encoded authorization identity.
   1.208 +   (Implementation note: The authorization identity is not terminated
   1.209 +   with the zero-valued (%x00) octet (e.g., the UTF-8 encoding of the
   1.210 +   NUL (U+0000) character)).  The client passes the data to GSS_Wrap
   1.211 +   with conf_flag set to FALSE and responds with the generated
   1.212 +   output_message.  The client can then consider the server
   1.213 +   authenticated.
   1.214 +
   1.215 +3.2.  Server Side of Authentication Protocol Exchange
   1.216 +
   1.217 +   A server MUST NOT advertise support for the "GSSAPI" SASL mechanism
   1.218 +   described in this document unless it has acceptor credential for the
   1.219 +   Kerberos V GSS-API mechanism [KRB5GSS].
   1.220 +
   1.221 +   The server passes the initial client response to
   1.222 +   GSS_Accept_sec_context as input_token, setting input_context_handle
   1.223 +   to 0 (initially), chan_binding of NULL, and a suitable
   1.224 +   acceptor_cred_handle (see below).  If GSS_Accept_sec_context returns
   1.225 +   GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
   1.226 +
   1.227 +
   1.228 +
   1.229 +Melnikov                    Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 4752                 SASL GSSAPI Mechanism             November 2006
   1.232 +
   1.233 +
   1.234 +   to the client in challenge and passes the resulting response to
   1.235 +   another call to GSS_Accept_sec_context, repeating the actions in this
   1.236 +   paragraph.
   1.237 +
   1.238 +   Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
   1.239 +   or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the Object
   1.240 +   Identifier (OID) of the Kerberos V5 GSS-API mechanism [KRB5GSS](*).
   1.241 +   Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle.
   1.242 +   Servers MAY use a credential obtained by calling GSS_Acquire_cred or
   1.243 +   GSS_Add_cred for the server's principal name(s) (**) and the Kerberos
   1.244 +   V5 GSS-API mechanism [KRB5GSS].
   1.245 +
   1.246 +   (*) Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of GSS-
   1.247 +   API mechanism as an input parameter.  The OID set can be created by
   1.248 +   using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can be
   1.249 +   freed by calling the GSS_Release_oid_set.
   1.250 +
   1.251 +
   1.252 +   (**) Use of server's principal names having
   1.253 +   GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
   1.254 +   where "service" is the service name specified in the protocol's
   1.255 +   profile, and "hostname" is the fully qualified host name of the
   1.256 +   server, is RECOMMENDED.  The server name is generated by calling
   1.257 +   GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE
   1.258 +   and input_name_string of "service@hostname".
   1.259 +
   1.260 +   Upon successful establishment of the security context (i.e.,
   1.261 +   GSS_Accept_sec_context returns GSS_S_COMPLETE), the server SHOULD
   1.262 +   verify that the negotiated GSS-API mechanism is indeed Kerberos V5
   1.263 +   [KRB5GSS].  This is done by examining the value of the mech_type
   1.264 +   parameter returned from the GSS_Accept_sec_context call.  If the
   1.265 +   value differs, SASL authentication MUST be aborted.
   1.266 +
   1.267 +   Upon successful establishment of the security context and if the
   1.268 +   server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
   1.269 +   credential handle, the server SHOULD also check using the
   1.270 +   GSS_Inquire_context that the target_name used by the client matches
   1.271 +   either
   1.272 +
   1.273 +   -  the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
   1.274 +      where "service" is the service name specified in the application
   1.275 +      protocol's profile,
   1.276 +
   1.277 +      or
   1.278 +
   1.279 +   -  the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two-
   1.280 +      component principal where the first component matches the service
   1.281 +      name specified in the application protocol's profile.
   1.282 +
   1.283 +
   1.284 +
   1.285 +Melnikov                    Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 4752                 SASL GSSAPI Mechanism             November 2006
   1.288 +
   1.289 +
   1.290 +   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
   1.291 +   examines the context to ensure that it provides a level of protection
   1.292 +   permitted by the server's security policy.  In particular, if the
   1.293 +   integ_avail flag is not set in the context, then no security layer
   1.294 +   can be offered or accepted.  If the conf_avail flag is not set in the
   1.295 +   context, then no security layer with confidentiality can be offered
   1.296 +   or accepted.
   1.297 +
   1.298 +   If the context is acceptable, the server takes the following actions:
   1.299 +   If the last call to GSS_Accept_sec_context returned an output_token,
   1.300 +   the server returns it to the client in a challenge and expects a
   1.301 +   reply from the client with no data.  Whether or not an output_token
   1.302 +   was returned (and after receipt of any response from the client to
   1.303 +   such an output_token), the server then constructs 4 octets of data,
   1.304 +   with the first octet containing a bit-mask specifying the security
   1.305 +   layers supported by the server and the second through fourth octets
   1.306 +   containing in network byte order the maximum size output_token the
   1.307 +   server is able to receive (which MUST be 0 if the server does not
   1.308 +   support any security layer).  The server must then pass the plaintext
   1.309 +   to GSS_Wrap with conf_flag set to FALSE and issue the generated
   1.310 +   output_message to the client in a challenge.
   1.311 +
   1.312 +   The server must then pass the resulting response to GSS_Unwrap and
   1.313 +   interpret the first octet of resulting cleartext as the bit-mask for
   1.314 +   the selected security layer, the second through fourth octets as the
   1.315 +   maximum size output_message the client is able to receive (in network
   1.316 +   byte order), and the remaining octets as the authorization identity.
   1.317 +   The server verifies that the client has selected a security layer
   1.318 +   that was offered and that the client maximum buffer is 0 if no
   1.319 +   security layer was chosen.  The server must verify that the src_name
   1.320 +   is authorized to act as the authorization identity.  After these
   1.321 +   verifications, the authentication process is complete.  The server is
   1.322 +   not expected to return any additional data with the success
   1.323 +   indicator.
   1.324 +
   1.325 +3.3.  Security Layer
   1.326 +
   1.327 +   The security layers and their corresponding bit-masks are as follows:
   1.328 +
   1.329 +          1 No security layer
   1.330 +          2 Integrity protection.
   1.331 +            Sender calls GSS_Wrap with conf_flag set to FALSE
   1.332 +          4 Confidentiality protection.
   1.333 +            Sender calls GSS_Wrap with conf_flag set to TRUE
   1.334 +
   1.335 +   Other bit-masks may be defined in the future; bits that are not
   1.336 +   understood must be negotiated off.
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Melnikov                    Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 4752                 SASL GSSAPI Mechanism             November 2006
   1.344 +
   1.345 +
   1.346 +   When decoding any received data with GSS_Unwrap, the major_status
   1.347 +   other than the GSS_S_COMPLETE MUST be treated as a fatal error.
   1.348 +
   1.349 +   Note that SASL negotiates the maximum size of the output_message to
   1.350 +   send.  Implementations can use the GSS_Wrap_size_limit call to
   1.351 +   determine the corresponding maximum size input_message.
   1.352 +
   1.353 +4.  IANA Considerations
   1.354 +
   1.355 +   IANA modified the existing registration for "GSSAPI" as follows:
   1.356 +
   1.357 +   Family of SASL mechanisms:  NO
   1.358 +
   1.359 +   SASL mechanism name:  GSSAPI
   1.360 +
   1.361 +   Security considerations:  See Section 5 of RFC 4752
   1.362 +
   1.363 +   Published specification:  RFC 4752
   1.364 +
   1.365 +   Person & email address to contact for further information:
   1.366 +      Alexey Melnikov <Alexey.Melnikov@isode.com>
   1.367 +
   1.368 +   Intended usage:  COMMON
   1.369 +
   1.370 +   Owner/Change controller:  iesg@ietf.org
   1.371 +
   1.372 +   Additional information:  This mechanism is for the Kerberos V5
   1.373 +      mechanism of GSS-API.
   1.374 +
   1.375 +5.  Security Considerations
   1.376 +
   1.377 +   Security issues are discussed throughout this memo.
   1.378 +
   1.379 +   When constructing the input_name_string, the client SHOULD NOT
   1.380 +   canonicalize the server's fully qualified domain name using an
   1.381 +   insecure or untrusted directory service.
   1.382 +
   1.383 +   For compatibility with deployed software, this document requires that
   1.384 +   the chan_binding (channel bindings) parameter to GSS_Init_sec_context
   1.385 +   and GSS_Accept_sec_context be NULL, hence disallowing use of GSS-API
   1.386 +   support for channel bindings.  GSS-API channel bindings in SASL is
   1.387 +   expected to be supported via a new GSS-API family of SASL mechanisms
   1.388 +   (to be introduced in a future document).
   1.389 +
   1.390 +   Additional security considerations are in the [SASL] and [GSS-API]
   1.391 +   specifications.  Additional security considerations for the GSS-API
   1.392 +   mechanism can be found in [KRB5GSS] and [KERBEROS].
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Melnikov                    Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 4752                 SASL GSSAPI Mechanism             November 2006
   1.400 +
   1.401 +
   1.402 +6.  Acknowledgements
   1.403 +
   1.404 +   This document replaces Section 7.2 of RFC 2222 [RFC2222] by John G.
   1.405 +   Myers.  He also contributed significantly to this revision.
   1.406 +
   1.407 +   Lawrence Greenfield converted text of this document to the XML
   1.408 +   format.
   1.409 +
   1.410 +   Contributions of many members of the SASL mailing list are gratefully
   1.411 +   acknowledged, in particular comments from Chris Newman, Nicolas
   1.412 +   Williams, Jeffrey Hutzelman, Sam Hartman, Mark Crispin, and Martin
   1.413 +   Rex.
   1.414 +
   1.415 +7.  Changes since RFC 2222
   1.416 +
   1.417 +   RFC 2078 [RFC2078] specifies the version of GSS-API used by RFC 2222
   1.418 +   [RFC2222], which provided the original version of this specification.
   1.419 +   That version of GSS-API did not provide the integ_integ_avail flag as
   1.420 +   an input to GSS_Init_sec_context.  Instead, integrity was always
   1.421 +   requested.  RFC 4422 [SASL] requires that when possible, the security
   1.422 +   layer negotiation be integrity protected.  To meet this requirement
   1.423 +   and as part of moving from RFC 2078 [RFC2078] to RFC 2743 [GSS-API],
   1.424 +   this specification requires that clients request integrity from
   1.425 +   GSS_Init_sec_context so they can use GSS_Wrap to protect the security
   1.426 +   layer negotiation.  This specification does not require that the
   1.427 +   mechanism offer the integrity security layer, simply that the
   1.428 +   security layer negotiation be wrapped.
   1.429 +
   1.430 +8.  References
   1.431 +
   1.432 +8.1.  Normative References
   1.433 +
   1.434 +   [GSS-API]  Linn, J., "Generic Security Service Application Program
   1.435 +              Interface Version 2, Update 1", RFC 2743, January 2000.
   1.436 +
   1.437 +   [KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
   1.438 +              Kerberos Network Authentication Service (V5)", RFC 4120,
   1.439 +              July 2005.
   1.440 +
   1.441 +   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   1.442 +              Requirement Levels", BCP 14, RFC 2119, March 1997.
   1.443 +
   1.444 +   [KRB5GSS]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
   1.445 +              1964, June 1996.
   1.446 +
   1.447 +
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Melnikov                    Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 4752                 SASL GSSAPI Mechanism             November 2006
   1.456 +
   1.457 +
   1.458 +   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
   1.459 +              Version 5 Generic Security Service Application Program
   1.460 +              Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
   1.461 +              2005.
   1.462 +
   1.463 +   [SASL]     Melnikov, A. and  K. Zeilenga, "Simple Authentication and
   1.464 +              Security Layer (SASL)", RFC 4422, June 2006.
   1.465 +
   1.466 +   [UTF8]     Yergeau, F., "UTF-8, a transformation format of ISO
   1.467 +              10646", STD 63, RFC 3629, November 2003.
   1.468 +
   1.469 +8.2.  Informative References
   1.470 +
   1.471 +   [RFC2078]  Linn, J., "Generic Security Service Application Program
   1.472 +              Interface, Version 2", RFC 2078, January 1997.
   1.473 +
   1.474 +   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
   1.475 +              (SASL)", RFC 2222, October 1997.
   1.476 +
   1.477 +Editor's Address
   1.478 +
   1.479 +   Alexey Melnikov
   1.480 +   Isode Limited
   1.481 +   5 Castle Business Village
   1.482 +   36 Station Road
   1.483 +   Hampton, Middlesex  TW12 2BX
   1.484 +   UK
   1.485 +
   1.486 +   EMail: Alexey.Melnikov@isode.com
   1.487 +   URI:   http://www.melnikov.ca/
   1.488 +
   1.489 +
   1.490 +
   1.491 +
   1.492 +
   1.493 +
   1.494 +
   1.495 +
   1.496 +
   1.497 +
   1.498 +
   1.499 +
   1.500 +
   1.501 +
   1.502 +
   1.503 +
   1.504 +
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Melnikov                    Standards Track                     [Page 9]
   1.510 +
   1.511 +RFC 4752                 SASL GSSAPI Mechanism             November 2006
   1.512 +
   1.513 +
   1.514 +Full Copyright Statement
   1.515 +
   1.516 +   Copyright (C) The IETF Trust (2006).
   1.517 +
   1.518 +   This document is subject to the rights, licenses and restrictions
   1.519 +   contained in BCP 78, and except as set forth therein, the authors
   1.520 +   retain all their rights.
   1.521 +
   1.522 +   This document and the information contained herein are provided on an
   1.523 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   1.524 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
   1.525 +   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   1.526 +   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   1.527 +   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   1.528 +   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   1.529 +   PURPOSE.
   1.530 +
   1.531 +Intellectual Property
   1.532 +
   1.533 +   The IETF takes no position regarding the validity or scope of any
   1.534 +   Intellectual Property Rights or other rights that might be claimed to
   1.535 +   pertain to the implementation or use of the technology described in
   1.536 +   this document or the extent to which any license under such rights
   1.537 +   might or might not be available; nor does it represent that it has
   1.538 +   made any independent effort to identify any such rights.  Information
   1.539 +   on the procedures with respect to rights in RFC documents can be
   1.540 +   found in BCP 78 and BCP 79.
   1.541 +
   1.542 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.543 +   assurances of licenses to be made available, or the result of an
   1.544 +   attempt made to obtain a general license or permission for the use of
   1.545 +   such proprietary rights by implementers or users of this
   1.546 +   specification can be obtained from the IETF on-line IPR repository at
   1.547 +   http://www.ietf.org/ipr.
   1.548 +
   1.549 +   The IETF invites any interested party to bring to its attention any
   1.550 +   copyrights, patents or patent applications, or other proprietary
   1.551 +   rights that may cover technology that may be required to implement
   1.552 +   this standard.  Please address the information to the IETF at
   1.553 +   ietf-ipr@ietf.org.
   1.554 +
   1.555 +Acknowledgement
   1.556 +
   1.557 +   Funding for the RFC Editor function is currently provided by the
   1.558 +   Internet Society.
   1.559 +
   1.560 +
   1.561 +
   1.562 +
   1.563 +
   1.564 +
   1.565 +Melnikov                    Standards Track                    [Page 10]
   1.566 +