draft-ietf-sasl-gs2-01.txt | draft-ietf-sasl-gs2.txt | |||
---|---|---|---|---|
Network Working Group S. Josefsson | Network Working Group S. Josefsson | |||
Expires: December 28, 2006 | Intended status: Standards Track | |||
Expires: June 10, 2007 | ||||
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family | Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family | |||
draft-ietf-sasl-gs2-01 | draft-ietf-sasl-gs2-04 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 33 | skipping to change at page 1, line 34 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on December 28, 2006. | This Internet-Draft will expire on June 10, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
This document describes how to use a Generic Security Service | This document describes how to use a Generic Security Service | |||
Application Program Interface (GSS-API) mechanism in the the Simple | Application Program Interface (GSS-API) mechanism in the the Simple | |||
Authentication and Security Layer (SASL) framework. | Authentication and Security Layer (SASL) framework. This is done by | |||
defining a new SASL mechanism family, called GS2. This mechanism | ||||
family offers a number of improvements over the previous SASL/GSS-API | ||||
mechanism: it is more general, uses fewer messages for the | ||||
authentication phase in some cases, and supports a SASL-specific | ||||
notion of channel binding. | ||||
See <http://josefsson.org/sasl-gs2-*/> for more information. | See <http://josefsson.org/sasl-gs2-*/> for more information. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Conventions Used in this Document . . . . . . . . . . . . . . 3 | 2. Conventions used in this document . . . . . . . . . . . . . . 3 | |||
3. Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3.1. Generating SASL Mechanism Names From GSS-API OIDs . . . . 3 | 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 4 | |||
3.2. Computing Mechanism Names Manually . . . . . . . . . . . . 4 | 3.2. Computing mechanism names manually . . . . . . . . . . . . 4 | |||
3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. SASL Authentication Exchange Message Format . . . . . . . . . 5 | |||
4.1. SASL Tokens . . . . . . . . . . . . . . . . . . . . . . . 4 | 4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 6 | |||
4.3. Context Token . . . . . . . . . . . . . . . . . . . . . . 6 | 4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.4. Wrap Token . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.4.1. Wrap Token Input For Client Requests . . . . . . . . . 7 | 4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.4.2. WraP Token Input For Server Responses . . . . . . . . 8 | 4.3.1. Client first GSS_Wrap input . . . . . . . . . . . . . 9 | |||
4.4.3. Wrap Token Input For Server Requests . . . . . . . . . 9 | 4.3.2. Server last GSS_Wrap input . . . . . . . . . . . . . . 10 | |||
4.4.4. Wrap Token Input For Client Responses . . . . . . . . 9 | 4.3.3. Server first GSS_Wrap input . . . . . . . . . . . . . 11 | |||
5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.3.4. Client last GSS_Wrap input . . . . . . . . . . . . . . 12 | |||
5.1. Name Of Tls Channel For Use As Channel Binding . . . . . . 11 | 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 | 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 | |||
7. Authentication Conditions . . . . . . . . . . . . . . . . . . 14 | 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 16 | |||
8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 14 | 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 16 | |||
9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 15 | 9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 16 | |||
10. Interoperability With The Gssapi Mechanism . . . . . . . . . . 15 | 9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
10.1. The Interoperability problem . . . . . . . . . . . . . . . 15 | 10. Interoperability with the GSSAPI mechanism . . . . . . . . . . 18 | |||
10.2. Resolving the problem . . . . . . . . . . . . . . . . . . 15 | 10.1. The interoperability problem . . . . . . . . . . . . . . . 18 | |||
10.3. Additional recommendations . . . . . . . . . . . . . . . . 15 | 10.2. Resolving the problem . . . . . . . . . . . . . . . . . . 18 | |||
11. Mechanisms That Negotiate Other Mechanisms . . . . . . . . . . 16 | 10.3. Additional recommendations . . . . . . . . . . . . . . . . 18 | |||
11.1. The Interoperability Problem . . . . . . . . . . . . . . . 16 | 11. Mechanisms that negotiate other mechanisms . . . . . . . . . . 18 | |||
11.2. Security Problem . . . . . . . . . . . . . . . . . . . . . 16 | 11.1. The interoperability problem . . . . . . . . . . . . . . . 19 | |||
11.3. Resolving the Problems . . . . . . . . . . . . . . . . . . 16 | 11.2. Security problem . . . . . . . . . . . . . . . . . . . . . 19 | |||
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 11.3. Resolving the problems . . . . . . . . . . . . . . . . . . 19 | |||
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
15. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 18 | 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 15. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 21 | |||
16.1. Normative References . . . . . . . . . . . . . . . . . . . 18 | 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
16.2. Informative References . . . . . . . . . . . . . . . . . . 19 | 16.1. Normative References . . . . . . . . . . . . . . . . . . . 21 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 16.2. Informative References . . . . . . . . . . . . . . . . . . 22 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 21 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 23 | ||||
1. Introduction | 1. Introduction | |||
Generic Security Service Application Program Interface (GSS-API) [3] | Generic Security Service Application Program Interface (GSS-API) [3] | |||
is a framework that provide security services to applications. | is a framework that provide security services to applications. | |||
Simple Authentication and Security Layer (SASL) [2] is a framework to | Simple Authentication and Security Layer (SASL) [2] is a framework to | |||
provide authentication and security layers for connection based | provide authentication and security layers for connection based | |||
protocols. This document describe how to use a GSS-API mechanism in | protocols. This document describe how to use a GSS-API mechanism in | |||
a connection-based protocol using the SASL framework. | a connection-based protocol using the SASL framework. | |||
All GSSAPI mechanisms are implicitly registered for use within SASL | All GSSAPI mechanisms are implicitly registered for use within SASL | |||
by this specification. The SASL mechanism defined in this document | by this specification. The SASL mechanism defined in this document | |||
is known as the GS2 family. | is known as the GS2 family. | |||
The "Kerberos V5 GSS-API mechanism" [9] is also supported in SASL | The "Kerberos V5 GSS-API mechanism" [10] is also supported in SASL | |||
through "SASL GSSAPI mechanisms" [11]. The difference between that | through "SASL GSSAPI mechanisms" [12]. The difference between that | |||
protocol and the one described here, is that this protocol offer more | protocol and the one described here, is that this protocol offer more | |||
features (i.e., channel bindings and round-trip optimizations) while | features (i.e., channel bindings and round-trip optimizations) while | |||
the other protocol is more widely deployed. There are | the other protocol is more widely deployed. There are | |||
interoperability concerns by having the same GSS-API mechanism | interoperability concerns by having the same GSS-API mechanism | |||
available under more than one SASL mechanism name, see the section | available under more than one SASL mechanism name, see the section | |||
"Interoperability with the GSSAPI mechanism" below. | "Interoperability with the GSSAPI mechanism" below. | |||
There are interoperability and security concerns if this SASL | There are interoperability and security concerns if this SASL | |||
mechanism is used together with a GSS-API mechanism that negotiate | mechanism is used together with a GSS-API mechanism that negotiate | |||
other GSS-API mechanisms (such as SPNEGO [10]), see the section | other GSS-API mechanisms (such as SPNEGO [11]), see the section | |||
"Mechanisms that negotiate other mechanisms" below. | "Mechanisms that negotiate other mechanisms" below. | |||
SASL mechanism names starting with "GS2-" are reserved for SASL | SASL mechanism names starting with "GS2-" are reserved for SASL | |||
mechanisms which conform to this document. | mechanisms which conform to this document. | |||
The IESG is considered to be the owner of all SASL mechanisms which | The IESG is considered to be the owner of all SASL mechanisms which | |||
conform to this document. This does not necessarily imply that the | conform to this document. This does not necessarily imply that the | |||
IESG is considered to be the owner of the underlying GSSAPI | IESG is considered to be the owner of the underlying GSSAPI | |||
mechanism. | mechanism. | |||
2. Conventions Used in this Document | 2. Conventions used in this document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [1]. | document are to be interpreted as described in [1]. | |||
3. Mechanism Name | 3. Mechanism name | |||
3.1. Generating SASL Mechanism Names From GSS-API OIDs | 3.1. Generating SASL mechanism names from GSS-API OIDs | |||
The SASL mechanism name for a GSS-API mechanism is the concatenation | The SASL mechanism name for a GSS-API mechanism is the concatenation | |||
of the string "GS2-" and the Base32 encoding [5] (with an upper case | of the string "GS2-" and the Base32 encoding [6] (with an upper case | |||
alphabet) of the first ten bytes of the binary SHA-1 hash [4] string | alphabet) of the first ten bytes of the binary SHA-1 hash [4] string | |||
computed over the ASN.1 DER encoding [7] of the GSS-API mechanism's | computed over the ASN.1 DER encoding [8], including the tag and | |||
Object Identifier. The Base32 rules on padding characters and | length octets, of the GSS-API mechanism's Object Identifier. The | |||
characters outside of the base32 alphabet are not relevant to this | Base32 rules on padding characters and characters outside of the | |||
use of Base32. If any padding or non-alphabet characters are | base32 alphabet are not relevant to this use of Base32. If any | |||
encountered, the name is not a GS2 family mechanism name. | padding or non-alphabet characters are encountered, the name is not a | |||
GS2 family mechanism name. | ||||
3.2. Computing Mechanism Names Manually | 3.2. Computing mechanism names manually | |||
The SASL mechanism name may be computed manually. This is useful | The SASL mechanism name may be computed manually. This is useful | |||
when the set of supported GSS-API mechanisms is known in advance. It | when the set of supported GSS-API mechanisms is known in advance. It | |||
also obliterate the need to implement Base32, SHA-1 and DER in the | also obliterate the need to implement Base32, SHA-1 and DER in the | |||
SASL mechanism. The computed mechanism name can be used directly in | SASL mechanism. The computed mechanism name can be used directly in | |||
the implementation, and the implementation need not concern itself | the implementation, and the implementation need not concern itself | |||
with that the mechanism is part of a mechanism family. | with that the mechanism is part of a mechanism family. | |||
3.3. Example | 3.3. Examples | |||
For example, the OID for the SPKM-1 mechanism [12] is | The OID for the SPKM-1 mechanism [13] is 1.3.6.1.5.5.1.1. The ASN.1 | |||
1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID is 06 07 2b 06 01 | DER encoding of the OID, including the tag and length, is (in hex) 06 | |||
05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is | 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is | |||
1cf8f42b5a9f80fae9f831226d5d9d56278661ad. The Base32 encoding of the | (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad. | |||
first ten bytes of this is "dt4pik22t6epv2py". Thus the SASL | Convert the first ten octets to binary, and re-group them in groups | |||
mechanism name for the SPKM-1 GSSAPI mechanism is "GS2- | of 5, and convert them back to decimal, which results in these | |||
DT4PIK22T6EPV2PY". | computations: | |||
4. Packet Format | hex: | |||
1c f8 f4 2b 5a 9f 80 fa e9 f8 | ||||
4.1. SASL Tokens | binary: | |||
00011100 11111000 11110100 00101011 01011010 | ||||
10011111 10000000 11111010 11101001 11111000 | ||||
All top-level SASL packets for the GS2 mechanism family follow the | binary in groups of 5: | |||
following format: | 00011 10011 11100 01111 01000 01010 11010 11010 | |||
10011 11110 00000 01111 10101 11010 01111 11000 | ||||
decimal of each group: | ||||
3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24 | ||||
Translating each decimal value using table 3 in Base32 [6] yields the | ||||
character sequence DT4PIK22T6APV2PY. Thus the SASL mechanism name | ||||
for the SPKM-1 GSSAPI mechanism is "GS2-DT4PIK22T6APV2PY". | ||||
The OID for the Kerberos V5 GSS-API mechanism [10] is | ||||
1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48 | ||||
86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa | ||||
93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to | ||||
binary, and re-group them in groups of 5, and convert them back to | ||||
decimal, which results in these computations: | ||||
hex: | ||||
82 d2 73 25 76 6b d6 c8 45 aa | ||||
binary: | ||||
10000010 11010010 01110011 00100101 01110110 | ||||
01101011 11010110 11001000 01000101 10101010 | ||||
binary in groups of 5: | ||||
10000 01011 01001 00111 00110 01001 01011 10110 | ||||
01101 01111 01011 01100 10000 10001 01101 01010 | ||||
decimal of each group: | ||||
16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10 | ||||
Translating each decimal value using table 3 in Base32 [6] yields the | ||||
character sequence QLJHGJLWNPLNQRNK. Thus the SASL mechanism name | ||||
for the Kerberos V5 GSSAPI mechanism is "GS2-QLJHGJLWNPLNQRNK". | ||||
4. SASL Authentication Exchange Message Format | ||||
4.1. SASL Messages | ||||
During the SASL authentication exchange for GS2, a number of messages | ||||
following the following format is sent between the client and server. | ||||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Context length | | | Context length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Flags | | | Wrap token length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| / | | / | |||
/ Context token / | / [Context token] / | |||
/ --------------------/ | / --------------------/ | |||
/ ---------------------/ / | / ---------------------/ / | |||
/--------------------/ / | /--------------------/ / | |||
/ [Wrap token] / | / [Wrap token] / | |||
/ / | / / | |||
/ | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The "Context length" field is a 4 octet (32 bit) integer encoded in | The "Context length" and "Wrap token length" fields each contain a 4 | |||
network byte order, it indicate the length of the "Context token" | octet (32 bit) integer encoded in network byte order, that indicate | |||
field. | the length of the "Context token" and "Wrap token" fields, | |||
respectively. A length of 0 means that a particular field is not | ||||
The "Flags" field is a 4 octet (32 bit) bitmask that holds flags that | present. | |||
influence the authentication process. | ||||
The "Context token" field contain a GSS-API context establishment | The "Context token" field, if present, contain a GSS-API context | |||
token generated by GSS_Init_sec_context or GSS_Accept_sec_context. | establishment token generated by GSS_Init_sec_context or | |||
GSS_Accept_sec_context. | ||||
The "Wrap token" field is optional, and if present will contain the | The "Wrap token" field, if present, contain the output generated by | |||
output generated by GSS_Wrap. | GSS_Wrap. | |||
The length field does not include the length of the length field | The fields need not be aligned to 32-bit a boundary. There is no | |||
itself. Whether the "Wrap token" field is included or not can be | padding between fields. | |||
infered from the length field; if the length field is shorter than | ||||
the entire packet size minus 4 octets, the "Wrap token" field is | ||||
present and begins after length+4 octets into the packet. The tokens | ||||
need not be aligned to 32-bit a boundary. There is no padding | ||||
between the tokens. | ||||
Packets shorter than 4 octets are invalid. If the length field is | Messages shorter than or equal to 12 octets are invalid. From that | |||
longer than the entire packet size, minus 4 octets, the packet is | it follows that at least one of the "Context token length" and the | |||
"Wrap token length" integers MUST be non-zero in a particular | ||||
message. If the sum of the length integers is longer than the entire | ||||
message size, minus 8 octets for the length fields, the message is | ||||
invalid. | invalid. | |||
4.2. Flags | During any successful authentication exchange, the client and server | |||
will each send exactly one (non-empty) "Wrap token". | ||||
Bit 0 signal whether GSS-API Channel bindings are used. It is only | ||||
useful in the first token sent from the client, and MUST be set to 0 | ||||
in all other tokens. The bit is called the "Native Channel Bindings" | ||||
bit. The client chooses whether to set this bit or not depending on | ||||
local policy or user requests. | ||||
The other bits are not specified and MUST be zero. If a bit is set | Conforming implementations MUST NOT send additional data after the | |||
that is not understood by the implementation, it MUST be ignored. | above message syntax, and MUST ignore additional data. To | |||
illustrate, implementations MUST NOT assume that the last "Wrap token | ||||
length" octets of the packet correspond to the "Wrap token", because | ||||
that would be incorrect if the packet contained additional data not | ||||
described by this document. | ||||
4.3. Context Token | 4.2. Context Token Field | |||
The format of the "Context token" field inside the SASL token are | The format of the "Context token" field inside the SASL token are | |||
defined by the GSS-API specifications, and the data is computed by | defined by the GSS-API specifications, and the data is computed by | |||
the GSS_Init_sec_context and GSS_Accept_sec_context functions. | the GSS_Init_sec_context (for the client) and GSS_Accept_sec_context | |||
(for the server) functions. | ||||
4.2.1. Client side | ||||
The client calls GSS_Init_sec_context, passing in | The client calls GSS_Init_sec_context, passing in | |||
input_context_handle of 0 (initially), mech_type of the GSSAPI | input_context_handle of GSS_C_NO_CONTEXT (initially), mech_type of | |||
mechanism for which this SASL mechanism is registered, the | the GSSAPI mechanism for which this SASL mechanism is registered, the | |||
chan_binding is set to NULL or the channel binding data depending on | chan_binding is set to NULL, and targ_name equal to output_name from | |||
the Native Channel Binding flag, and targ_name equal to output_name | GSS_Import_Name called with input_name_type of | |||
from GSS_Import_Name called with input_name_type of | GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of | |||
GSS_C_NT_HOSTBASED_SERVICE and input_name_string of | ||||
"service@hostname" where "service" is the service name specified in | "service@hostname" where "service" is the service name specified in | |||
the protocol's profile, and "hostname" is the fully qualified host | the protocol's profile, and "hostname" is the fully qualified host | |||
name of the server. If the client will be requesting a security | name of the server. | |||
(*) - Clients MAY use name types other than | ||||
GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but | ||||
only when they have a priori knowledge that the servers support | ||||
alternate name types. Otherwise clients MUST use | ||||
GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names. | ||||
When calling the GSS_Init_sec_context the client MUST pass the | ||||
integ_req_flag of TRUE. If the client intends to request a security | ||||
layer, it MUST also supply to the GSS_Init_sec_context a | layer, it MUST also supply to the GSS_Init_sec_context a | |||
mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an | mutual_req_flag of TRUE, and a sequence_req_flag of TRUE. If the | |||
integ_req_flag of TRUE. If the client will be requesting a security | client will be requesting a security layer providing confidentiality | |||
layer providing confidentiality protection, it MUST also supply to | protection, it MUST also supply to the GSS_Init_sec_context a | |||
the GSS_Init_sec_context a conf_req_flag of TRUE. If | conf_req_flag of TRUE. | |||
GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client | ||||
should expect the server to issue a token in a subsequent challenge | The client then responds with any resulting output_token. | |||
If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the | ||||
client expect the server to issue a token in a subsequent challenge | ||||
or as additional information to the outcome of the authentication. | or as additional information to the outcome of the authentication. | |||
The client must pass the context token to another call to | The client pass the context token to another call to | |||
GSS_Init_sec_context, repeating the actions in this paragraph, until | GSS_Init_sec_context, repeating the procedure, until GSS_S_COMPLETE | |||
GSS_S_COMPLETE is returned or authentication is aborted. If the | is returned or authentication is aborted. | |||
server supply data beyond the context token, the context token should | ||||
be processed first, and then the overflow data should be passed to | ||||
GSS_Unwrap and the unwrapped data should be interpreted. During the | ||||
authentication exchange, the client will generate one Wrap token | ||||
using GSS_Wrap. | ||||
The server passes the first client response to GSS_Accept_sec_context | If the server sent a (non-empty) "Wrap token", the context token is | |||
as input_token, setting input_context_handle to 0 (initially), | processed before processing the other tokens. This is required | |||
mech_type of the GSSAPI mechanism for which this SASL mechanism is | because GSS_Unwrap may need the context to be in the state it is | |||
registered, the chan_binding set to NULL or the channel binding data | after the "Context token" in the message has been processed. | |||
depending on the Native Channel Binding bit, and acceptor_cred_handle | ||||
equal to output_cred_handle from GSS_Acquire_cred called with | ||||
desired_name equal to output_name from GSS_Import_name with | ||||
input_name_type of GSS_C_NT_HOSTBASED_SERVICE and input_name_string | ||||
of "service@hostname" where "service" is the service name specified | ||||
in the protocol's profile, and "hostname" is the fully qualified host | ||||
name of the server. The server must pass any resulting challenge | ||||
from the client to another call to GSS_Accept_sec_context, repeating | ||||
the actions in this paragraph, until GSS_S_COMPLETE is returned or | ||||
authentication is aborted. If the client supply data beyond the | ||||
context token, the context token should be processed first, and then | ||||
the overflow data should be passed to GSS_Unwrap and the unwrapped | ||||
data should be interpreted. During the authentication exchange, the | ||||
server will generate one Wrap token using GSS_Wrap. | ||||
4.4. Wrap Token | When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines | |||
the context to ensure that it provides a level of protection | ||||
permitted by the client's security policy. | ||||
The Wrap token MUST NOT be sent before the PROT_READY flag has been | 4.2.2. Server side | |||
set locally (by GSS_Init_sec_context or Gss_Accept_sec_context), or | ||||
if the PROT_READY flag is never set, before the context has been | The server passes the first context token to GSS_Accept_sec_context | |||
fully established. The GSS_Wrap token does not have to be sent | as input_token, setting input_context_handle to GSS_C_NO_CONTEXT | |||
directly when the PROT_READY flag is set. During any exchange, | (initially), the chan_binding set to NULL, and a suitable | |||
exactly one GSS_Wrap token is sent in each direction. The input to | acceptor_cred_handle (see below). | |||
the GSS_Wrap function MUST follow the format described below. If not | ||||
exactly one GSS_Wrap token is received by the client and by the | Servers SHOULD use a credential obtained by calling GSS_Acquire_cred | |||
server, the authentication MUST fail. | or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the | |||
GSS-API mechanism for which this SASL mechanism is registered (*). | ||||
Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle. | ||||
Servers MAY use a credential obtained by calling GSS_Acquire_cred or | ||||
GSS_Add_cred for the server's principal name(s) (**) and the GSS-API | ||||
mechanism for which this SASL mechanism is registered. | ||||
(*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of | ||||
GSS-API mechanism as an input parameter. The OID set can be created | ||||
by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can | ||||
be freed by calling the GSS_Release_oid_set. | ||||
(**) - Use of server's principal names having | ||||
GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format, | ||||
where "service" is the service name specified in the protocol's | ||||
profile, and "hostname" is the fully qualified host name of the | ||||
server, is RECOMMENDED. The server name can be generated by calling | ||||
GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE | ||||
and input_name_string of "service@hostname". | ||||
The server then responds with any resulting output_token. | ||||
The server pass any resulting challenge from the client to another | ||||
call to GSS_Accept_sec_context, repeating the procedure, until | ||||
GSS_S_COMPLETE is returned or authentication is aborted. | ||||
If the client sent a (non-empty) "Wrap token" , the context token is | ||||
processed first. | ||||
Upon successful establishment of the security context (i.e. | ||||
GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD | ||||
verify that the negotiated GSS-API mechanism is indeed the registered | ||||
one. This is done by examining the value of the mech_type parameter | ||||
returned from the GSS_Accept_sec_context call. If the value differ, | ||||
the SASL authentication MUST be aborted. | ||||
Upon successful establishment of the security context and if the | ||||
server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor | ||||
credential handle, the server SHOULD also check using the | ||||
GSS_Inquire_context that the target_name used by the client matches: | ||||
- the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax, | ||||
where "service" is the service name specified in the application | ||||
protocol's profile, and "hostname" is the fully qualified host name | ||||
of the server. | ||||
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server | ||||
examines the context to ensure that it provides a level of protection | ||||
permitted by the server's security policy. | ||||
4.3. Wrap Token Field | ||||
The Wrap token field MUST NOT be sent or received before the | ||||
PROT_READY flag is set locally (by GSS_Init_sec_context or | ||||
Gss_Accept_sec_context), or if the PROT_READY flag is never set, | ||||
before the context has been fully established. The Wrap token field | ||||
does not have to be present directly when the PROT_READY flag is set. | ||||
During any exchange, exactly one Wrap token field is sent in each | ||||
direction. The input to the GSS_Wrap function MUST follow the format | ||||
described below. If not exactly one Wrap token is received by the | ||||
client and by the server, the authentication MUST fail. | ||||
If PROT_READY is never set by GSS_Init_sec_context or | If PROT_READY is never set by GSS_Init_sec_context or | |||
GSS_Accept_sec_context, the flag is implied by successful context | GSS_Accept_sec_context, the flag is implied by successful context | |||
negotiation. This is for GSS-API v1 mechanisms that do not support | negotiation. This is for GSS-API v1 mechanisms that do not support | |||
PROT_READY. This may result in a SASL token consisting of a context | PROT_READY. This may result in a SASL token consisting of a context | |||
token length of 0 and a Wrap token. | token length of 0 and a Wrap token. | |||
The entity that sends its first Wrap token will have to specify a | The entity that sends its first Wrap token will have to specify a | |||
bitmap of supported and preferred quality of protection schemes. The | bitmap of supported and preferred quality of protection schemes. The | |||
entity that reply to the Wrap tokens will pick a scheme, based on the | entity that replies to the Wrap tokens will pick a scheme, based on | |||
bitmask and local policy. | the bitmask and local policy. The quality of protection values are | |||
defined in section 9. | ||||
Four input formats to the GSS_Wrap function are defined. The first | Two pairs of input formats to the GSS_Wrap function are defined. The | |||
two input formats are used when the client sends the GSS_Wrap token | first pair is used when the client sends the GSS_Wrap token first and | |||
first and the server reponds. The other two input formats are used | the server responds. The other pair is used when the server sends | |||
when the server sends the GSS_Wrap token first and the client | the GSS_Wrap token first and the client responds. | |||
responds. | ||||
The input formats below are passed to GSS_Wrap with conf_flag set to | The inputs below are passed to GSS_Wrap with conf_flag set to FALSE, | |||
FALSE, and the Wrap token output will be the generated | and the Wrap token will be the generated output_message. | |||
output_message. | ||||
Some fields in the input formats are optional, indicated by brackets | Some fields in the input formats are optional, indicated by brackets | |||
("[" and "]") and explained by the text below. | ("[" and "]") and explained by the text below. | |||
4.4.1. Wrap Token Input For Client Requests | 4.3.1. Client first GSS_Wrap input | |||
The input to GSS_Wrap when the client sends the GSS_Wrap token first | The input to GSS_Wrap when the client sends a Wrap token field first | |||
is as follows. | is as follows. | |||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| client_qops | client_maxbuf | | | client_qops | client_maxbuf | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| channel_binding_length | | | channel_binding_length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|[client_cbqops]| [channel_binding_data] / | |[client_cbqops]| [channel_binding_data] / | |||
/ / | / / | |||
/ / [authzid] / | / / [authzid] / | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The "client_qops" integer indicate the client's preferred quality of | The "client_qops" integer indicate the client's preferred quality of | |||
protection if channel bindings are absent or the negotiation of the | protection if channel bindings are absent or the negotiation of the | |||
channel binding fails. | channel binding fails. The quality of protection values are defined | |||
in section 9. | ||||
The "client_maxbuf" field indicate the maximum protected buffer size | The "client_maxbuf" field indicate the maximum protected buffer size | |||
the client can receive. | the client can receive in network byte order. It MUST be 0 if the | |||
client doesn't advertise support for any security layer, the server | ||||
MUST verify this. Small values can make it impossible for the server | ||||
to send any protected message to the client, due to the overhead | ||||
added by GSS_Wrap, and the server MAY reject the authentication if it | ||||
detects this situation. | ||||
The "channel_binding_length" is a network byte order integer that | The "channel_binding_length" is a network byte order integer that | |||
indicate the length of the "channel_binding_data" field. | indicate the length of the "channel_binding_data" field. | |||
The optional field "client_cbqops" is present only if | The optional field "client_cbqops" is present only if | |||
"channel_binding_length" is non-zero, and indicate the client's | "channel_binding_length" is non-zero, and indicate the client's | |||
preferred quality of protection if channel binding negotiation | preferred quality of protection if channel binding negotiation | |||
succeeds. | succeeds. The quality of protection values are defined in section 9. | |||
The optional field "channel_binding_data" is present only if | The optional field "channel_binding_data" is present only if | |||
"channel_binding_length" is non-zero, and contain the actual channel | "channel_binding_length" is non-zero, and contain the actual channel | |||
binding data. | binding data. | |||
The optional field "authzid" contain the authorization identity. The | The optional field "authzid" contain the authorization identity. The | |||
authorization identity is encoded using UTF-8 [6]. The authorization | authorization identity is encoded using UTF-8 [5]. The authorization | |||
identity is not terminated with the NUL (U+0000) character. Servers | identity is not terminated with the NUL (U+0000) character. Servers | |||
MUST validate that the authorization identity is valid UTF-8. | MUST validate that the authorization identity is valid UTF-8. | |||
4.4.2. WraP Token Input For Server Responses | 4.3.2. Server last GSS_Wrap input | |||
The data format for input to GSS_Wrap when the server responds to the | The input to GSS_Wrap when the server sends a Wrap token field, after | |||
previous GSS_Wrap token data is as follows. | receiving the Wrap token in the previous section from the client, is | |||
as follows. | ||||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| server_qop | server_maxbuf | | | server_qop | server_maxbuf | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The "server_qop" field integer indicate the selected quality of | The "server_qop" field integer indicate the selected quality of | |||
protection. | protection. The quality of protection values are defined in section | |||
9. | ||||
The "server_maxbuf" field indicate the maximum data buffer size the | The "server_maxbuf" field indicate the maximum protected data buffer | |||
server can receive. It MUST be 0 if the server doesn't advertise | size the server can receive in network byte order. It MUST be 0 if | |||
support for any security layer, the client MUST verify this. | the server doesn't advertise support for any security layer, the | |||
client MUST verify this. Small values can make it impossible for the | ||||
client to send any protected message to the server, due to the | ||||
overhead added by GSS_Wrap, and the client MAY reject the | ||||
authentication if it detects this situation. | ||||
4.4.3. Wrap Token Input For Server Requests | 4.3.3. Server first GSS_Wrap input | |||
The data format for input to GSS_Wrap when the server sends the | The input to GSS_Wrap when the server sends the Wrap token first is | |||
GSS_Wrap token first is as follows. | as follows. | |||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| server_qops | server_maxbuf | | | server_qops | server_maxbuf | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| channel_binding_length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|[server_cbqops]| [channel_binding_data] / | |[server_cbqops]| [channel_binding_data] / | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The "server_qops" field is an integer indicating the server's | The "server_qops" field is an integer indicating the server's | |||
preferred quality of protection if channel bindings are absent or the | preferred quality of protection if channel bindings are absent or the | |||
negotiation of the channel binding fails. | negotiation of the channel binding fails. The quality of protection | |||
values are defined in section 9. | ||||
The "server_maxbuf" is the same as above. | The "server_maxbuf" is the same as above. | |||
The "channel_binding_length" is a network byte order integer that | The optional field "server_cbqops" indicate the server's preferred | |||
indicate the length of the "channel_binding_data" field. | quality of protection if channel binding negotiation succeeds. The | |||
quality of protection values are defined in section 9. | ||||
The optional field "server_cbqops" is present only if | ||||
"channel_binding_length" is non-zero, and indicate the server's | ||||
preferred quality of protection if channel binding negotiation | ||||
succeeds. | ||||
The optional field "channel_binding_data" is present only if | The optional field "channel_binding_data" contain the actual channel | |||
"channel_binding_length" is non-zero, and contain the actual channel | ||||
binding data. | binding data. | |||
4.4.4. Wrap Token Input For Client Responses | 4.3.4. Client last GSS_Wrap input | |||
The data format for input to GSS_Wrap when the client responds to the | The input to GSS_Wrap when the clients sends a Wrap token field, | |||
previous token is as follows. | after receiving the Wrap token in the previous section from the | |||
server, is as follows. | ||||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| client_qop | client_maxbuf | | | client_qop | client_maxbuf | | |||
/ [authzid] | | / [authzid] | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The "client_qop" field is the selected quality of protection. | The "client_qop" field is the selected quality of protection. The | |||
quality of protection values are defined in section 9. | ||||
The "client_maxbuf" and "authzid" fields are as above. | The "client_maxbuf" and "authzid" fields are as above. | |||
5. Channel Bindings | 5. Channel Bindings | |||
[[This section is tentative further discussion on the topic. This | The GS2 mechanism provide its own channel binding mechanism, instead | |||
was written to provide an example of how the details of how one | of using the "chan_binding" parameter in the GSS-API context | |||
approach to this concept could look like. There are other approaches | functions. The reason for this is that the GS2 mechanism provide an | |||
that may be preferable.]] | option to proceed even if the channel bindings does not match. The | |||
GSS-API framework specifies that authentication cannot proceed if | ||||
The GS2 mechanism provide its own token field for channel bindings, | channel bindings do not match. | |||
in addition to the "chan_binding" parameter in the GSS-API context | ||||
functions. The reason for this is that the GS2 mechanism wish to | ||||
provide an option to proceed even if the channel bindings does not | ||||
match. The GSS-API framework specifies that authentication cannot | ||||
proceed if channel bindings does not match. The GSS-API framework | ||||
also does not specify the kind of privacy layer the channel binding | ||||
should be transferred under, thus making it possible for attackers to | ||||
modify it to always make channel binding negotiation succeed. | ||||
The client can select, using the "Native Channel Bindings" bit, | ||||
whether it wishes to use the "chan_bindings" parameter in the GSS-API | ||||
layer or not. If it wishes to use this, it is not possible to | ||||
continue after a failed channel binding negotiation. | ||||
A client that wish to continue with the authentication even if the | ||||
channel bindings does not match, set the "Native Channel Binding" bit | ||||
to 0. It MUST use the channel binding field in the GS2 token. It | ||||
MUST set the "chan_binding" parameter in the calls to | ||||
GSS_Init_sec_context to GSS_Accept_sec_context to NULL. The | ||||
application MUST set the "client_qops" field to include privacy | ||||
protection (to protect the SASL application data), and MAY set the | ||||
"client_cbqops" to no security layer (to avoid performance | ||||
degradation due to two security layers). | ||||
If a client do not wish to continue the authentication if channel | ||||
binding negotiation fails, or wishes to use the channel binding in | ||||
the GSS-API layer, it will set the "Native Channel Binding" bit to 1 | ||||
in its first token. It MUST use both the channel binding field in | ||||
the GS2 token and the "chan_binding" parameter in the calls to | ||||
GSS_Init_sec_context and GSS_Accept_sec_context. The authentication | ||||
will fail in the GSS-API layer if the channel bindings does not | ||||
match, and thus the "client_qops" and "client_cbqops" MUST be set to | ||||
the same value. It MAY be set to no security layer (to avoid | ||||
performance degradation due to two security layers). | ||||
For TLS, the channel binding data is specified in the next section. | ||||
For other security layers, channel binding data will have to | ||||
specified elsewhere, and this specification will have to be updated | ||||
with explicit considerations. | ||||
[[All channel bindings should go into a separate document.]] | ||||
5.1. Name Of Tls Channel For Use As Channel Binding | ||||
The TLS Pseudo-Random Function (PRF) generate, using the constant | Client and servers MUST set the "chan_binding" parameter in the calls | |||
string "TLS channel binding", and based on the master secret and the | to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to | |||
random values established during a TLS handshake, a 64 octet string | NULL. | |||
that make up the SASL channel binding data. | ||||
Using the terminology of TLS [13], the channel binding data is | Implementations SHOULD set the "client_cbqops" and "server_cbqops" to | |||
computed as follows: | no security layer and instead depend on the session security afforded | |||
by the bound-in channel. | ||||
SASL_channel_binding = | Use of no SASL security layers in combination with channel binding | |||
PRF(SecurityParameters.master_secret, | should provide better performance than using SASL security layers | |||
"TLS channel binding", | over secure channels, and better security characteristics than using | |||
SecurityParameters.server_random + | no SASL security layers over secure channels without channel binding. | |||
SecurityParameters.client_random) [0..64]; | ||||
The derived data is intended to be used as a name of the TLS channel | For more discussions of channel bindings, and the syntax of the | |||
that is cryptographically bound to the channel, for use in | channel binding data for various security protocols, see [7]. | |||
authentication mechanisms tunneled over TLS. | ||||
6. Protocol Overview | 6. Protocol Overview | |||
This section describe several high-level protocol exchanges. The | This section describe several high-level protocol exchanges. The | |||
descriptions do not assume any properties of the actual GSS-API | descriptions do not assume any properties of the actual GSS-API | |||
mechanism. Protocol profiles, GSS-API mechanism specific behaviour, | mechanism. Protocol profiles, GSS-API mechanism specific behaviour, | |||
and to some extent implementation and policy choices, will dictate | and to some extent implementation and policy choices, will dictate | |||
which packets are sent in what order. The protocol exchanges are | which packets are sent in what order. The protocol exchanges are | |||
examples and other exchanges are permitted and will occur. | examples and other exchanges are permitted and will occur. | |||
An informal pseudo-language is used to describe the packets sent | ||||
below. In particular, when GSS_Wrap() is mentioned below, it refer | ||||
to the operation of calling GSS_Wrap on the indicated fields, | ||||
formatted in the structures described earlier. | ||||
An authentication exchange using GS2 may look like: | An authentication exchange using GS2 may look like: | |||
C: Request authentication exchange | C: Request authentication exchange | |||
S: Send [length=0] token | S: Send [length=0] token | |||
C: Send [length, GSS_Init_sec_context] token | C: Send [length, GSS_Init_sec_context] token | |||
... | ... | |||
S: After PROT_READY is set, | S: After PROT_READY is set, | |||
send [length, GSS_Accept_sec_context, | send [length, GSS_Accept_sec_context, | |||
GSS_Wrap(server_qops, server_maxbuf, | GSS_Wrap(server_qops | server_maxbuf] | |||
channel_binding_length=0)] | ||||
... | ... | |||
C: After PROT_READY is set, | C: After PROT_READY is set, | |||
send [length, GSS_Init_sec_context, | send [length, GSS_Init_sec_context, | |||
GSS_Wrap (client_qop, client_maxbuf, authzid)] | GSS_Wrap (client_qop | client_maxbuf | authzid)] | |||
S: Send [length, GSS_Accept_sec_context] token | S: Send [length, GSS_Accept_sec_context] token | |||
C: Send [length, GSS_Init_sec_context] token | C: Send [length, GSS_Init_sec_context] token | |||
... | ... | |||
S: Outcome of authentication exchange | S: Outcome of authentication exchange | |||
Because GSS-API authentication is initiated by the client, the length | Because GSS-API authentication is initiated by the client, the length | |||
field will be 0 in the initial token from the server to the client | field will be 0 in the initial token from the server to the client | |||
when the protocol profile do not support additional information to be | when the protocol profile does not support additional information to | |||
sent together with the authentication request. | be sent together with the authentication request. | |||
The next example illustrate when the client sends its Wrap token | The next example illustrate when the client sends its Wrap token | |||
first. | first. | |||
C: Request authentication exchange | C: Request authentication exchange | |||
S: Send [length=0] token | S: Send [length=0] token | |||
C: Send [length, GSS_Init_sec_context] token | C: Send [length, GSS_Init_sec_context] token | |||
... | ... | |||
C: After PROT_READY is set, | C: After PROT_READY is set, | |||
send [length, GSS_Init_sec_context, | send [length, GSS_Init_sec_context, | |||
GSS_Wrap(client_qops, client_maxbuf, | GSS_Wrap(client_qops | client_maxbuf | | |||
channel_binding_length=0, authzid)] | channel_binding_length=0 | authzid)] | |||
... | ... | |||
S: After PROT_READY is set, | S: After PROT_READY is set, | |||
send [length, GSS_Accept_sec_context, | send [length, GSS_Accept_sec_context, | |||
GSS_Wrap (server_qop, server_maxbuf)] | GSS_Wrap (server_qop | server_maxbuf)] | |||
C: Send [length, GSS_Init_sec_context] token | C: Send [length, GSS_Init_sec_context] token | |||
S: Send [length, GSS_Accept_sec_context] token | S: Send [length, GSS_Accept_sec_context] token | |||
... | ... | |||
S: Outcome of authentication exchange | S: Outcome of authentication exchange | |||
If the protocol profile support the optional initial client response, | If the protocol profile support the optional initial client response, | |||
the first empty message can be optimized away, and then the protocol | the first empty message can be optimized away, and then the protocol | |||
exchange will look like: | exchange will look like: | |||
C: Request authentication exchange and | C: Request authentication exchange and | |||
skipping to change at page 13, line 32 | skipping to change at page 15, line 9 | |||
as additional information. | as additional information. | |||
If the PROT_READY flag is never set by the GSS-API mechanism, the | If the PROT_READY flag is never set by the GSS-API mechanism, the | |||
GSS_Wrap message will be sent after the context has been established. | GSS_Wrap message will be sent after the context has been established. | |||
The protocol may look like: | The protocol may look like: | |||
C: Request authentication exchange | C: Request authentication exchange | |||
... | ... | |||
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs | S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs | |||
a token, send [length, context token, | a token, send [length, context token, | |||
GSS_Wrap(server_qops, server_maxbuf, | GSS_Wrap(server_qops | server_maxbuf)] | |||
channel_binding_length=0)] | ||||
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not | C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not | |||
output a token, send | output a token, send | |||
[length=0, context token, | [length=0, context token, | |||
GSS_Wrap(client_qop, client_maxbuf, | GSS_Wrap(client_qop | client_maxbuf | | |||
channel_binding_length=0, authzid)] | channel_binding_length=0 | authzid)] | |||
S: Outcome of authentication exchange | S: Outcome of authentication exchange | |||
Alternatively, if the client finishes first, it may look like: | Alternatively, if the client finishes first, it may look like: | |||
C: Request authentication exchange | C: Request authentication exchange | |||
... | ... | |||
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a | C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a | |||
token, send [length, context token, | token, send [length, context token, | |||
GSS_Wrap(client_qops, client_maxbuf, | GSS_Wrap(client_qops | client_maxbuf | | |||
channel_binding_length=0, authzid)] | channel_binding_length=0 | authzid)] | |||
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not | S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not | |||
output a token, send [length, context token, | output a token, send [length, context token, | |||
GSS_Wrap(server_qop, server_maxbuf, | GSS_Wrap(server_qop | server_maxbuf | | |||
channel_binding_length=0)] | ||||
S: Outcome of authentication exchange | ||||
Adding channel bindings to the last examples, gives the following | ||||
situation. Here the client request confidentiality for the | ||||
application data if channel binding fails but no SASL security layer | ||||
if channel binding negotiation succeeds: | ||||
C: Request authentication exchange | ||||
... | ||||
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a | ||||
token, send [length, context token, | ||||
GSS_Wrap(client_qops=0x04 | client_maxbuf | | ||||
channel_binding_length=n | | ||||
client_cbqops=0x01 | channel_binding_data | | ||||
authzid)] | ||||
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not | ||||
output a token, send [length, context token, | ||||
GSS_Wrap(server_qop | server_maxbuf | | ||||
channel_binding_length=0)] | channel_binding_length=0)] | |||
S: Outcome of authentication exchange | S: Outcome of authentication exchange | |||
If the protocol support initial data from the client, and the | If the protocol support initial data from the client, and the | |||
PROT_READY flag is set in the client after the first call to | PROT_READY flag is set in the client after the first call to | |||
GSS_Init_sec_context, and the server can send additional data to the | GSS_Init_sec_context, and the server can send additional data to the | |||
client when indicating successful authentication, the following | client when indicating successful authentication, the following | |||
protocol exchange will occur. | protocol exchange will occur. | |||
C: Request authentication exchange and | C: Request authentication exchange and | |||
send [length, GSS_Init_sec_context, | send [length, GSS_Init_sec_context, | |||
GSS_Wrap (client_qops, client_maxbuf, | GSS_Wrap (client_qops | client_maxbuf | | |||
channel_binding_length=0, authzid)] token | channel_binding_length=0 | authzid)] token | |||
S: Indicate successful authentication and | S: Indicate successful authentication and | |||
send [length, GSS_Accept_sec_context, | send [length, GSS_Accept_sec_context, | |||
GSS_Wrap(server_qop, server_maxbuf)] token | GSS_Wrap(server_qop | server_maxbuf)] token | |||
as additional information. | as additional information. | |||
The last example illustrate the optimal (round-trip wise) | The last example illustrate the optimal (round-trip wise) | |||
authentication possible using this protocol. | authentication possible using this protocol. | |||
7. Authentication Conditions | 7. Authentication Conditions | |||
Authentication MUST NOT succeed if any one of the following | Authentication MUST NOT succeed if any one of the following | |||
conditions are true: | conditions are true: | |||
o An invalid SASL token is received (i.e., length shorter than 4 | o An invalid SASL token is received (i.e., length shorter than 4 | |||
octets). | octets). | |||
o GSS_Init/Accept_sec_context() return anything other than | o GSS_Init/Accept_sec_context() return anything other than | |||
GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. | GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. | |||
o GSS_Wrap() returns anything other than GSS_S_COMPLETE. | o GSS_Wrap() returns anything other than GSS_S_COMPLETE. | |||
o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There | o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There | |||
can't be supplementary status codes in GS2 at this point, so any | can't be supplementary status codes in GS2 at this point, so any | |||
indications of out of order processing or replays should be | indications of out of order processing or replays is fatal.) | |||
fatal.) | ||||
o The token returned from GSS_Unwrap fail to parse correctly (e.g., | o The token returned from GSS_Unwrap fail to parse correctly (e.g., | |||
too short, invalid maximum buffer size) as the expected Wrap | too short, invalid maximum buffer size) as the expected Wrap | |||
token. | token. | |||
o Local policy reject the attempt. For example, client and server | o Local policy reject the attempt. For example, client and server | |||
can't agree on qop proposal. | can't agree on qop proposal. | |||
o (server-side) Authorization of client principal (i.e., src_name in | o (server-side) Authorization of client principal (i.e., src_name in | |||
GSS_Acecpt_sec_context) to requested authzid failed. | GSS_Acecpt_sec_context) to requested authzid failed. | |||
8. GSS-API Parameters | 8. GSS-API Parameters | |||
The implementation MAY set any GSSAPI flags or arguments not | The implementation MAY set any GSSAPI flags or arguments not | |||
mentioned in this specification as is necessary for the | mentioned in this specification as is necessary for the | |||
implementation to enforce its security policy. | implementation to enforce its security policy. | |||
9. Security Layer Bits | 9. Security Layer Bits | |||
The fields "client_qops", "server_qops", "client_cbqops", and | ||||
"server_cbqops" are bit-fields that encode a set of requested quality | ||||
of protection. The fields "client_qop" and "server_qop" encode a | ||||
single quality of protection value. | ||||
The "client_qop" and "server_qop" will contains the chosen security | ||||
layer. | ||||
Note that "client_qop" and "server_qop" MAY indicate a quality of | ||||
protection that was not offered by the server and client, | ||||
respectively. This SHOULD only be used when the server or client | ||||
(respectively) would otherwise fail the entire authentication | ||||
exchange. The server/client that receives a "client_qop"/ | ||||
"server_qop" MUST verify that it corresponds to an acceptable | ||||
security level. | ||||
The security layers and their corresponding bit-masks are as follows: | The security layers and their corresponding bit-masks are as follows: | |||
1 No security layer | 1 No security layer | |||
2 Integrity protection. | 2 Integrity protection. | |||
Sender calls GSS_Wrap with conf_flag set to FALSE | Sender calls GSS_Wrap with conf_flag set to FALSE | |||
4 Confidentiality protection. | 4 Confidentiality protection. | |||
Sender calls GSS_Wrap with conf_flag set to TRUE | Sender calls GSS_Wrap with conf_flag set to TRUE | |||
Other bit-masks may be defined in the future; bits which are not | Other bit-masks may be defined in the future; bits which are not | |||
understood must be negotiated off. | understood MUST be negotiated off. | |||
Note that SASL negotiates the maximum size of the output_message to | When decoding any received data with GSS_Unwrap the major_status | |||
send. Implementations can use the GSS_Wrap_size_limit call to | other than the GSS_S_COMPLETE MUST be treated as a fatal error. | |||
determine the corresponding maximum size input_message. | ||||
10. Interoperability With The Gssapi Mechanism | For integrity and confidentiality protection, GS2 negotiates the | |||
maximum size of the output_message to send. Implementations can use | ||||
the GSS_Wrap_size_limit call to determine the corresponding maximum | ||||
size input_message. | ||||
The GSSAPI mechanism [11] describe how the Kerberos V5 GSS-API | 9.1. Examples | |||
mechanism [9] is used in SASL under the mechanism name "GSSAPI". The | ||||
same mechanism may also be used with the GS2 family. This causes an | ||||
interopability problem, which is discussed and resolved below. | ||||
10.1. The Interoperability problem | When no security layer is negotiated the octet will encode an integer | |||
1 as follows. | ||||
0 1 2 3 4 5 6 7 | ||||
+-+-+-+-+-+-+-+-+ | ||||
|0|0|0|0|0|0|0|1| | ||||
+-+-+-+-+-+-+-+-+ | ||||
When integrity is negotiated the octet will encode an integer 2 as | ||||
follows. | ||||
0 1 2 3 4 5 6 7 | ||||
+-+-+-+-+-+-+-+-+ | ||||
|0|0|0|0|0|0|1|0| | ||||
+-+-+-+-+-+-+-+-+ | ||||
When confidentiality is negotiated the octet will encode an integer 4 | ||||
as follows. | ||||
0 1 2 3 4 5 6 7 | ||||
+-+-+-+-+-+-+-+-+ | ||||
|0|0|0|0|0|1|0|0| | ||||
+-+-+-+-+-+-+-+-+ | ||||
10. Interoperability with the GSSAPI mechanism | ||||
The GSSAPI mechanism [12] describe how the Kerberos V5 GSS-API | ||||
mechanism [10] is used in SASL under the mechanism name "GSSAPI". | ||||
The same mechanism may also be used with the GS2 family. This causes | ||||
an interopability problem, which is discussed and resolved below. | ||||
10.1. The interoperability problem | ||||
If a client (or server) only support Kerberos V5 under the "GSSAPI" | If a client (or server) only support Kerberos V5 under the "GSSAPI" | |||
name and the server (or client) only support Kerberos V5 under the | name and the server (or client) only support Kerberos V5 under the | |||
GS2 family, the authentication negotiation will fail. | GS2 family, the authentication negotiation will fail. | |||
10.2. Resolving the problem | 10.2. Resolving the problem | |||
If the Kerberos V5 mechanism is supported under GS2 in a server, the | If the Kerberos V5 mechanism is supported under GS2 in a server, the | |||
server SHOULD also support Kerberos V5 through the "GSSAPI" | server SHOULD also support Kerberos V5 through the "GSSAPI" | |||
mechanism, to avoid interoperability problems with older clients. | mechanism, to avoid interoperability problems with older clients. | |||
Reasons for violating this recommendation may include security | Reasons for violating this recommendation may include security | |||
considerations regarding the absent features in the GS2 mechanism. | considerations regarding the absent features in the GS2 mechanism. | |||
The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which | The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which | |||
could enable certain tunnel attacks [16]. | could enable certain tunnel attacks [17]. | |||
10.3. Additional recommendations | 10.3. Additional recommendations | |||
It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism | It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism | |||
rather than through the "GSSAPI" mechanism, if both are available, | rather than through the "GSSAPI" mechanism, if both are available, | |||
because of the additional features in the GS2 mechanism. | because of the additional features in the GS2 mechanism. | |||
11. Mechanisms That Negotiate Other Mechanisms | 11. Mechanisms that negotiate other mechanisms | |||
A GSS-API mechanism that negotiate other mechanisms interact badly | A GSS-API mechanism that negotiate other mechanisms interact badly | |||
with the SASL mechanism negotiation. There are two problems. The | with the SASL mechanism negotiation. There are two problems. The | |||
first is an interoperability problem and the second is a security | first is an interoperability problem and the second is a security | |||
concern. The problems are described and resolved below. | concern. The problems are described and resolved below. | |||
11.1. The Interoperability Problem | 11.1. The interoperability problem | |||
If a client implement GSS-API mechanism X, potentially negotiated | If a client implement GSS-API mechanism X, potentially negotiated | |||
through a GSS-API mechanism Y, and the server also implement GSS-API | through a GSS-API mechanism Y, and the server also implement GSS-API | |||
mechanism X negotiated through a GSS-API mechanism Z, the | mechanism X negotiated through a GSS-API mechanism Z, the | |||
authentication negotiation will fail. | authentication negotiation will fail. | |||
11.2. Security Problem | 11.2. Security problem | |||
If a client's policy is to first prefer GSSAPI mechanism X, then non- | If a client's policy is to first prefer GSSAPI mechanism X, then non- | |||
GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports | GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports | |||
mechanisms Y and Z but not X, then if the client attempts to | mechanisms Y and Z but not X, then if the client attempts to | |||
negotiate mechanism X by using a GSS-API mechanism that negotiate | negotiate mechanism X by using a GSS-API mechanism that negotiate | |||
other mechanisms (such as SPNEGO), it may end up using mechanism Z | other mechanisms (such as SPNEGO), it may end up using mechanism Z | |||
when it should have used mechanism Y. For this reason, the use of | when it ideally should have used mechanism Y. For this reason, the | |||
GSS-API mechanisms that negotiate other mechanisms are disallowed | use of GSS-API mechanisms that negotiate other mechanisms are | |||
under GS2. | disallowed under GS2. | |||
11.3. Resolving the Problems | 11.3. Resolving the problems | |||
GSS-API mechanisms that negotiate other mechanisms MUST NOT be used | GSS-API mechanisms that negotiate other mechanisms MUST NOT be used | |||
with the GS2 SASL mechanism. This specifically exclude negotiating | with the GS2 SASL mechanism. This specifically exclude negotiating | |||
SPNEGO [10] under GS2. | SPNEGO [11] under GS2. | |||
The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [15] | The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [16] | |||
can be used to identify such mechanisms. | can be used to identify such mechanisms. | |||
12. IANA Considerations | 12. IANA Considerations | |||
The IANA is advised that SASL mechanism names starting with "GS2-" | The IANA is advised that SASL mechanism names starting with "GS2-" | |||
are reserved for SASL mechanisms which conform to this document. The | are reserved for SASL mechanisms which conform to this document. The | |||
IANA is directed to place a statement to that effect in the sasl- | IANA is directed to place a statement to that effect in the sasl- | |||
mechanisms registry. | mechanisms registry. | |||
Subject: Registration of SASL mechanism GS2-* | Subject: Registration of SASL mechanism GS2-* | |||
Family of SASL mechanisms: YES | ||||
SASL mechanism prefix: GS2- | SASL mechanism prefix: GS2- | |||
Security considerations: RFC [THIS-DOC] | Security considerations: RFC [THIS-DOC] | |||
Published specification: RFC [THIS-DOC] | Published specification: RFC [THIS-DOC] | |||
Person & email address to contact for further information: | Person & email address to contact for further information: | |||
Simon Josefsson <simon@josefsson.org> | Simon Josefsson <simon@josefsson.org> | |||
Intended usage: COMMON | Intended usage: COMMON | |||
Owner/Change controller: iesg@ietf.org | Owner/Change controller: iesg@ietf.org | |||
Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms. | Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms. | |||
13. Security Considerations | 13. Security Considerations | |||
Security issues are discussed throughout this memo. | Security issues are discussed throughout this memo. | |||
When a server or client supports multiple authentication mechanisms, | When a server or client supports multiple authentication mechanisms, | |||
each of which has a different security strength, it is possible for | each of which has a different security strength, it is possible for | |||
an active attacker to cause a party to use the least secure mechanism | an active attacker to cause a party to use the least secure mechanism | |||
supported. There are several ways to mitigate this problem: | supported. There are several ways to mitigate this problem: | |||
1. Integrity protected transports can be used, e.g., TLS [13]. To | 1. Integrity protected transports can be used, e.g., TLS [14]. To | |||
protect against certain tunnel attacks [16] with that solution, a | protect against certain tunnel attacks [17] with that solution, a | |||
mechanism that support channel bindings that can bind the | mechanism that support channel bindings that can bind the | |||
security layer (e.g., the TLS session id) to the authentication | security layer (e.g., the TLS session id) to the authentication | |||
is required. | is required. | |||
2. A client or server which supports mechanisms of different | 2. A client or server which supports mechanisms of different | |||
strengths should have a configurable minimum strength that it | strengths should have a configurable minimum strength that it | |||
will use. It is not sufficient for this minimum strength check | will use. It is not sufficient for this minimum strength check | |||
to only be on the server, since an active attacker can change | to only be on the server, since an active attacker can change | |||
which mechanisms the client sees as being supported, causing the | which mechanisms the client sees as being supported, causing the | |||
client to send authentication credentials for its weakest | client to send authentication credentials for its weakest | |||
supported mechanism. | supported mechanism. | |||
Because the negotiation of a GSS-API mechanism may be done in the | Because the negotiation of a GSS-API mechanism may be done in the | |||
clear, it is important for the GSS-API mechanisms to be designed such | clear, it is important for the GSS-API mechanisms to be designed such | |||
that an active attacker cannot obtain an authentication with weaker | that an active attacker cannot obtain an authentication with weaker | |||
security properties by modifying the challenges and responses. | security properties by modifying the challenges and responses. | |||
The integrity protection provided by the security layer is useless to | The channel binding is sent without privacy protection and knowledge | |||
the client unless the client also requests mutual authentication. | of it is assumed to provide no advantage to an attacker. This is a | |||
Therefore, a client wishing to benefit from the integrity protection | property that has to be considered when specifying channel bindings | |||
of a security layer MUST pass to the GSS_Init_sec_context call a | for a security protocol. | |||
mutual_req_flag of TRUE. | ||||
When constructing the input_name_string, the client should not | When constructing the input_name_string, the client should not | |||
canonicalize the server's fully qualified domain name using an | canonicalize the server's fully qualified domain name using an | |||
insecure or untrusted directory service, e.g., the Domain Name System | insecure or untrusted directory service, e.g., the Domain Name System | |||
[8] without DNSSEC [14]. | [9] without DNSSEC [15]. | |||
Additional security considerations are in the SASL and GSSAPI | Additional security considerations are in the SASL and GSSAPI | |||
specifications. Additional security considerations for the Kerberos | specifications. Additional security considerations for the Kerberos | |||
V5 GSSAPI mechanism can be found in [9]. We stress that service | V5 GSSAPI mechanism can be found in [10]. We stress that service | |||
names should not be canonicalized using an unsecured directory | names should not be canonicalized using an unsecured directory | |||
service such as the DNS without DNSSEC. | service such as the DNS without DNSSEC. | |||
14. Acknowledgements | 14. Acknowledgements | |||
This document is a revision of RFC 2222. This version was derived | This document is a revision of RFC 2222. This version was derived | |||
from draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov | from draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov | |||
with significant contributions from John G. Myers, although this | with significant contributions from John G. Myers, although the | |||
document has been rewritten by the current author. | majority of this document has been rewritten by the current author. | |||
Contributions of many members of the SASL mailing list are gratefully | Contributions of many members of the SASL mailing list are gratefully | |||
acknowledged. In particular, ideas from Sam Hartman, Jeffrey | acknowledged. In particular, ideas and feedback from Sam Hartman, | |||
Hutzelman, and Nicolas Williams influenced the design of this | Jeffrey Hutzelman, Alexey Melnikov, and Nicolas Williams influenced | |||
protocol. | the design of the document and protocol. | |||
15. Copying Conditions | 15. Copying Conditions | |||
Copyright (C) 2005, 2006 Simon Josefsson | ||||
Regarding the portion of this document that was written by Simon | Regarding the portion of this document that was written by Simon | |||
Josefsson ("the author", for the remainder of this section), the | Josefsson ("the author", for the remainder of this section), the | |||
author makes no guarantees and is not responsible for any damage | author makes no guarantees and is not responsible for any damage | |||
resulting from its use. The author grants irrevocable permission to | resulting from its use. The author grants irrevocable permission to | |||
anyone to use, modify, and distribute it in any way that does not | anyone to use, modify, and distribute it in any way that does not | |||
diminish the rights of anyone else to use, modify, and distribute it, | diminish the rights of anyone else to use, modify, and distribute it, | |||
provided that redistributed derivative works do not contain | provided that redistributed derivative works do not contain | |||
misleading author or version information. Derivative works need not | misleading author or version information. Derivative works need not | |||
be licensed under similar terms. Contact the author to confirm which | be licensed under similar terms. Contact the author to confirm which | |||
sections are available under this license. | sections are available under this license. | |||
16. References | 16. References | |||
16.1. Normative References | 16.1. Normative References | |||
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
Levels", BCP 14, RFC 2119, March 1997. | Levels", BCP 14, RFC 2119, March 1997. | |||
[2] Myers, J., "Simple Authentication and Security Layer (SASL)", | [2] Melnikov, A. and K. Zeilenga, "Simple Authentication and | |||
RFC 2222, October 1997. | Security Layer (SASL)", RFC 4422, June 2006. | |||
[3] Linn, J., "Generic Security Service Application Program | [3] Linn, J., "Generic Security Service Application Program | |||
Interface Version 2, Update 1", RFC 2743, January 2000. | Interface Version 2, Update 1", RFC 2743, January 2000. | |||
[4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", | [4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", | |||
RFC 3174, September 2001. | RFC 3174, September 2001. | |||
[5] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", | [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", | |||
draft-josefsson-rfc3548bis-04 (work in progress), May 2006. | ||||
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", | ||||
STD 63, RFC 3629, November 2003. | STD 63, RFC 3629, November 2003. | |||
[7] "Information Processing Systems - Open Systems Interconnection - | [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", | |||
Specification of Abstract Syntax Notation One (ASN.1)", ISO | RFC 4648, October 2006. | |||
Standard 8824. | ||||
[7] Williams, N., "On the Use of Channel Bindings to Secure | ||||
Channels", draft-ietf-nfsv4-channel-bindings-04 (work in | ||||
progress), June 2006. | ||||
[8] International Organization for Standardization, "Information | ||||
Processing Systems - Open Systems Interconnection - | ||||
Specification of Abstract Syntax Notation One (ASN.1)", | ||||
ISO Standard 8824, December 1990. | ||||
16.2. Informative References | 16.2. Informative References | |||
[8] Mockapetris, P., "Domain names - concepts and facilities", | [9] Mockapetris, P., "Domain names - concepts and facilities", | |||
STD 13, RFC 1034, November 1987. | STD 13, RFC 1034, November 1987. | |||
[9] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, | [10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, | |||
June 1996. | June 1996. | |||
[10] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API | [11] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API | |||
Negotiation Mechanism", RFC 2478, December 1998. | Negotiation Mechanism", RFC 2478, December 1998. | |||
[11] Melnikov, A., "SASL GSSAPI mechanisms", | [12] Melnikov, A., "SASL GSSAPI mechanisms", | |||
draft-ietf-sasl-gssapi-03 (work in progress), September 2005. | draft-ietf-sasl-gssapi-03 (work in progress), September 2005. | |||
[12] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", | [13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", | |||
RFC 2025, October 1996. | RFC 2025, October 1996. | |||
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | [14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) | |||
RFC 2246, January 1999. | Protocol Version 1.1", RFC 4346, April 2006. | |||
[14] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | [15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | |||
"DNS Security Introduction and Requirements", RFC 4033, | "DNS Security Introduction and Requirements", RFC 4033, | |||
March 2005. | March 2005. | |||
[15] Williams, N., "Extended Generic Security Service Mechanism | [16] Williams, N., "Extended Generic Security Service Mechanism | |||
Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-01 (work | Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-01 (work | |||
in progress), October 2005. | in progress), October 2005. | |||
[16] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in | [17] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in | |||
Tunneled Authentication", | Tunneled Authentication", | |||
WWW http://www.saunalahti.fi/~asokan/research/mitm.html. | WWW http://www.saunalahti.fi/~asokan/research/mitm.html. | |||
Author's Address | Author's Address | |||
Simon Josefsson | Simon Josefsson | |||
Email: simon@josefsson.org | Email: simon@josefsson.org | |||
Intellectual Property Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2006). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
skipping to change at page 21, line 29 | skipping to change at page 23, line 45 | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Disclaimer of Validity | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Copyright Statement | ||||
Copyright (C) The Internet Society (2006). This document is subject | ||||
to the rights, licenses and restrictions contained in BCP 78, and | ||||
except as set forth therein, the authors retain all their rights. | ||||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
Internet Society. | Administrative Support Activity (IASA). | |||
End of changes. 114 change blocks. | ||||
343 lines changed or deleted | 484 lines changed or added | |||
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |