archive-org.com » ORG » J » JOSEFSSON.ORG

Total: 236

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".

  • 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 Josefsson Expires September 30 2007 Page 10 Internet Draft SASL GS2 March 2007 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 MUST examine 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 GS2 Wrap function is defined below and its inputs 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 GSS Accept sec context the flag is implied by successful context negotiation This is for GSS API v1 mechanisms that do not support PROT READY or for GSS API mechanism that do not provide per message protection This may result in a SASL token consisting of a context token length of 0 and a Wrap token The entity that sends the first Wrap token will have to specify a bitmap of supported and preferred quality of protection schemes The entity that replies to the Wrap tokens will pick a scheme based on the bitmask and local policy The quality of protection values are defined in section 9 Two pairs of input formats to the GS2 Wrap function are defined The first pair is used when the client sends the Wrap token first and the server responds The other pair is used when the server sends the Josefsson Expires September 30 2007 Page 11 Internet Draft SASL GS2 March 2007 Wrap token first and the client responds The inputs below are passed to GS2 Wrap and the output is used as the Wrap token value Some fields in the input formats are optional indicated by brackets and and explained by the text below 4 3 1 The GS2 Wrap function The GS2 Wrap function have two implementations and which one is used depends on whether the negotiated GSS API context supports per message protection When a context is successfully negotiated i e when GSS S COMPLETE is returned from for clients GSS Init sec context or for servers GSS Accept sec context and the output variable integ avail is FALSE then GSS Wrap cannot be used and instead we define GS2 Wrap to be the identity function When integ avail is negotiated TRUE the GS2 Wrap is identical to calling the GSS Wrap function with conf flag set to FALSE and using the generated output message as the output data 4 3 2 Client first GS2 Wrap input The input to GS2 Wrap when the client sends a Wrap token field first 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 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 channel binding length client cbqops channel binding data authzid The client qops integer indicate the client s preferred quality of protection if channel bindings are absent or the negotiation of the 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 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 Josefsson Expires September 30 2007 Page 12 Internet Draft SASL GS2 March 2007 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 indicate the length of the channel binding data field The optional field client cbqops is present only if channel binding length is non zero and indicate the client s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 5 The authorization identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 4 3 3 Server last GS2 Wrap input The input to GS2 Wrap when the server sends a Wrap token field after 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 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 The server qop field integer indicate the selected quality of protection The quality of protection values are defined in section 9 The server maxbuf field indicate the maximum protected data buffer size the server can receive in network byte order It MUST be 0 if 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 3 4 Server first GS2 Wrap input The input to GS2 Wrap when the server sends the Wrap token first is as follows Josefsson Expires September 30 2007 Page 13 Internet Draft SASL GS2 March 2007 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 server qops server maxbuf server cbqops channel binding data The server qops field is an integer indicating the server s preferred quality of protection if channel bindings are absent or the 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 optional field server cbqops indicate the server s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data contain the actual channel binding data 4 3 5 Client last GS2 Wrap input The input to GS2 Wrap when the clients sends a Wrap token field 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 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 authzid 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 Josefsson Expires September 30 2007 Page 14 Internet Draft SASL GS2 March 2007 5 Channel Bindings The GS2 mechanism provide its own channel binding mechanism instead of using the chan binding parameter in the GSS API context functions The reason for this is that the GS2 mechanism 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 do not match Client and servers MUST set the chan binding parameter in the calls to GSS Init sec context and GSS Accept sec context respectively to NULL Implementations SHOULD set the client cbqops and server cbqops to no security layer and instead depend on the session security afforded by the bound in channel Use of no SASL security layers in combination with channel binding should provide better performance than using SASL security layers over secure channels and better security characteristics than using no SASL security layers over secure channels without channel binding For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see 8 For easy reference the channel binding format used for The Transport Layer Security TLS Protocol 14 is specified in 16 Josefsson Expires September 30 2007 Page 15 Internet Draft SASL GS2 March 2007 6 Protocol Overview This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur An informal pseudo language is used to describe the packets sent below GS2 Wrap refer to the operation of calling GS2 Wrap on the indicated fields formatted in the structures described earlier GSS Init sec context and GSS Accept sec context refer to the context token generated by calling the respective function The GS2 SASL Message is denoted as Context token Wrap token and the length fields are not mentioned An authentication exchange using GS2 may look like C Request authentication exchange S Send token C Send GSS Init sec context token S After PROT READY is set send GSS Accept sec context GS2 Wrap server qops server maxbuf C After PROT READY is set send GSS Init sec context GS2 Wrap client qop client maxbuf authzid S Send GSS Accept sec context token C Send GSS Init sec context token S Outcome of authentication exchange 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 when the protocol profile does not support additional information to be sent together with the authentication request The next example illustrate when the client sends its Wrap token first Josefsson Expires September 30 2007 Page 16 Internet Draft SASL GS2 March 2007 C Request authentication exchange S Send token C Send GSS Init sec context token C After PROT READY is set send GSS Init sec context GS2 Wrap client qops client maxbuf channel binding length 0 authzid S After PROT READY is set send GSS Accept sec context GS2 Wrap server qop server maxbuf C Send GSS Init sec context token S Send GSS Accept sec context token S Outcome of authentication exchange If the protocol profile support the optional initial client response the first empty message can be optimized away and then the protocol exchange will look like C Request authentication exchange and send GSS Init sec context token S Send GSS Accept sec context token S Outcome of authentication exchange If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol exchange will look like C Request authentication exchange and send GSS Init sec context token S Send GSS Accept sec context token C Send GSS Init sec context token S Indicate successful authentication and send GSS Accept sec context token as additional information If the PROT READY flag is never set by the GSS API mechanism the GS2 Wrap message will be sent after the context has been established The protocol may look like Josefsson Expires September 30 2007 Page 17 Internet Draft SASL GS2 March 2007 C Request authentication exchange S GSS Accept sec context returns GSS S COMPLETE and outputs a token send GS2 Wrap server qops server maxbuf C GSS Init sec context returns GSS S COMPLETE and does not output a token send GS2 Wrap client qop client maxbuf channel binding length 0 authzid S Outcome of authentication exchange Alternatively if the client finishes first it may look like C Request authentication exchange C GSS Init sec context returns GSS S COMPLETE and outputs a token send GS2 Wrap client qops client maxbuf channel binding length 0 authzid S GSS Accept sec context returns GSS S COMPLETE and does not output a token send GS2 Wrap server qop server maxbuf channel binding length 0 S Outcome of authentication exchange Adding channel bindings to the last examples gives the following complex 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 GSS Init sec context GS2 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 GS2 Wrap server qop server maxbuf channel binding length 0 S Outcome of authentication exchange If the protocol support initial data from the client and the 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 client when indicating successful authentication the following protocol exchange will occur Josefsson Expires September 30 2007 Page 18 Internet Draft SASL GS2 March 2007 C Request authentication exchange and send GSS Init sec context GS2 Wrap client qops client maxbuf channel binding length 0 authzid token S Indicate successful authentication and send GSS Accept sec context GS2 Wrap server qop server maxbuf token as additional information The last example illustrate the optimal round trip wise authentication possible using this protocol Josefsson Expires September 30 2007 Page 19 Internet Draft SASL GS2 March 2007 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received i e length shorter than 4 octets o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Unwrap returns anything other than GSS S COMPLETE There can t be supplementary status codes in GS2 at this point so any indications of out of order processing or replays is fatal o The token returned from GSS Unwrap fail to parse correctly e g too short invalid maximum buffer size as the expected Wrap token o Local policy reject the attempt For example client and server can t agree on qop proposal o server side Authorization of client principal i e src name in GSS Acecpt sec context to requested authzid failed Josefsson Expires September 30 2007 Page 20 Internet Draft SASL GS2 March 2007 8 GSS API Parameters The implementation MAY set any GSSAPI flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy Josefsson Expires September 30 2007 Page 21 Internet Draft SASL GS2 March 2007 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

    Original URL path: http://www.josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-08.txt (2016-04-30)
    Open archived version from archive



  • 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 Josefsson Expires September 1 2007 Page 10 Internet Draft SASL GS2 February 2007 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 MUST examine 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 GS2 Wrap function is defined below and its inputs 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 GSS Accept sec context the flag is implied by successful context negotiation This is for GSS API v1 mechanisms that do not support PROT READY or for GSS API mechanism that do not provide per message protection This may result in a SASL token consisting of a context token length of 0 and a Wrap token The entity that sends the first Wrap token will have to specify a bitmap of supported and preferred quality of protection schemes The entity that replies to the Wrap tokens will pick a scheme based on the bitmask and local policy The quality of protection values are defined in section 9 Two pairs of input formats to the GS2 Wrap function are defined The first pair is used when the client sends the Wrap token first and the server responds The other pair is used when the server sends the Josefsson Expires September 1 2007 Page 11 Internet Draft SASL GS2 February 2007 Wrap token first and the client responds The inputs below are passed to GS2 Wrap and the output is used as the Wrap token value Some fields in the input formats are optional indicated by brackets and and explained by the text below 4 3 1 The GS2 Wrap function The GS2 Wrap function have two implementations and which one is used depends on whether the negotiated GSS API context supports per message protection When a context is successfully negotiated i e when GSS S COMPLETE is returned from for clients GSS Init sec context or for servers GSS Accept sec context and the output variable integ avail is FALSE then GSS Wrap cannot be used and instead we define GS2 Wrap to be the identity function When integ avail is negotiated TRUE the GS2 Wrap is identical to calling the GSS Wrap function with conf flag set to FALSE and using the generated output message as the output data 4 3 2 Client first GS2 Wrap input The input to GS2 Wrap when the client sends a Wrap token field first 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 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 channel binding length client cbqops channel binding data authzid The client qops integer indicate the client s preferred quality of protection if channel bindings are absent or the negotiation of the 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 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 Josefsson Expires September 1 2007 Page 12 Internet Draft SASL GS2 February 2007 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 indicate the length of the channel binding data field The optional field client cbqops is present only if channel binding length is non zero and indicate the client s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 5 The authorization identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 4 3 3 Server last GS2 Wrap input The input to GS2 Wrap when the server sends a Wrap token field after 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 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 The server qop field integer indicate the selected quality of protection The quality of protection values are defined in section 9 The server maxbuf field indicate the maximum protected data buffer size the server can receive in network byte order It MUST be 0 if 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 3 4 Server first GS2 Wrap input The input to GS2 Wrap when the server sends the Wrap token first is as follows Josefsson Expires September 1 2007 Page 13 Internet Draft SASL GS2 February 2007 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 server qops server maxbuf server cbqops channel binding data The server qops field is an integer indicating the server s preferred quality of protection if channel bindings are absent or the 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 optional field server cbqops indicate the server s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data contain the actual channel binding data 4 3 5 Client last GS2 Wrap input The input to GS2 Wrap when the clients sends a Wrap token field 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 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 authzid 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 Josefsson Expires September 1 2007 Page 14 Internet Draft SASL GS2 February 2007 5 Channel Bindings The GS2 mechanism provide its own channel binding mechanism instead of using the chan binding parameter in the GSS API context functions The reason for this is that the GS2 mechanism 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 do not match Client and servers MUST set the chan binding parameter in the calls to GSS Init sec context and GSS Accept sec context respectively to NULL Implementations SHOULD set the client cbqops and server cbqops to no security layer and instead depend on the session security afforded by the bound in channel Use of no SASL security layers in combination with channel binding should provide better performance than using SASL security layers over secure channels and better security characteristics than using no SASL security layers over secure channels without channel binding For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see 8 For easy reference the channel binding format used for The Transport Layer Security TLS Protocol 14 is specified in 16 Josefsson Expires September 1 2007 Page 15 Internet Draft SASL GS2 February 2007 6 Protocol Overview This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur An informal pseudo language is used to describe the packets sent below GS2 Wrap refer to the operation of calling GS2 Wrap on the indicated fields formatted in the structures described earlier GSS Init sec context and GSS Accept sec context refer to the context token generated by calling the respective function The GS2 SASL Message is denoted as Context token Wrap token and the length fields are not mentioned An authentication exchange using GS2 may look like C Request authentication exchange S Send token C Send GSS Init sec context token S After PROT READY is set send GSS Accept sec context GS2 Wrap server qops server maxbuf C After PROT READY is set send GSS Init sec context GS2 Wrap client qop client maxbuf authzid S Send GSS Accept sec context token C Send GSS Init sec context token S Outcome of authentication exchange 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 when the protocol profile does not support additional information to be sent together with the authentication request The next example illustrate when the client sends its Wrap token first Josefsson Expires September 1 2007 Page 16 Internet Draft SASL GS2 February 2007 C Request authentication exchange S Send token C Send GSS Init sec context token C After PROT READY is set send GSS Init sec context GS2 Wrap client qops client maxbuf channel binding length 0 authzid S After PROT READY is set send GSS Accept sec context GS2 Wrap server qop server maxbuf C Send GSS Init sec context token S Send GSS Accept sec context token S Outcome of authentication exchange If the protocol profile support the optional initial client response the first empty message can be optimized away and then the protocol exchange will look like C Request authentication exchange and send GSS Init sec context token S Send GSS Accept sec context token S Outcome of authentication exchange If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol exchange will look like C Request authentication exchange and send GSS Init sec context token S Send GSS Accept sec context token C Send GSS Init sec context token S Indicate successful authentication and send GSS Accept sec context token as additional information If the PROT READY flag is never set by the GSS API mechanism the GS2 Wrap message will be sent after the context has been established The protocol may look like Josefsson Expires September 1 2007 Page 17 Internet Draft SASL GS2 February 2007 C Request authentication exchange S GSS Accept sec context returns GSS S COMPLETE and outputs a token send GS2 Wrap server qops server maxbuf C GSS Init sec context returns GSS S COMPLETE and does not output a token send GS2 Wrap client qop client maxbuf channel binding length 0 authzid S Outcome of authentication exchange Alternatively if the client finishes first it may look like C Request authentication exchange C GSS Init sec context returns GSS S COMPLETE and outputs a token send GS2 Wrap client qops client maxbuf channel binding length 0 authzid S GSS Accept sec context returns GSS S COMPLETE and does not output a token send GS2 Wrap server qop server maxbuf channel binding length 0 S Outcome of authentication exchange Adding channel bindings to the last examples gives the following complex 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 GSS Init sec context GS2 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 GS2 Wrap server qop server maxbuf channel binding length 0 S Outcome of authentication exchange If the protocol support initial data from the client and the 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 client when indicating successful authentication the following protocol exchange will occur Josefsson Expires September 1 2007 Page 18 Internet Draft SASL GS2 February 2007 C Request authentication exchange and send GSS Init sec context GS2 Wrap client qops client maxbuf channel binding length 0 authzid token S Indicate successful authentication and send GSS Accept sec context GS2 Wrap server qop server maxbuf token as additional information The last example illustrate the optimal round trip wise authentication possible using this protocol Josefsson Expires September 1 2007 Page 19 Internet Draft SASL GS2 February 2007 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received i e length shorter than 4 octets o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Unwrap returns anything other than GSS S COMPLETE There can t be supplementary status codes in GS2 at this point so any indications of out of order processing or replays is fatal o The token returned from GSS Unwrap fail to parse correctly e g too short invalid maximum buffer size as the expected Wrap token o Local policy reject the attempt For example client and server can t agree on qop proposal o server side Authorization of client principal i e src name in GSS Acecpt sec context to requested authzid failed Josefsson Expires September 1 2007 Page 20 Internet Draft SASL GS2 February 2007 8 GSS API Parameters The implementation MAY set any GSSAPI flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy Josefsson Expires September 1 2007 Page 21 Internet Draft SASL GS2 February 2007 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

    Original URL path: http://www.josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-07.txt (2016-04-30)
    Open archived version from archive


  • 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 Josefsson Expires August 10 2007 Page 10 Internet Draft SASL GS2 February 2007 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 MUST examine 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 GS2 Wrap function is defined below and its inputs 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 GSS Accept sec context the flag is implied by successful context negotiation This is for GSS API v1 mechanisms that do not support PROT READY or for GSS API mechanism that do not provide per message protection This may result in a SASL token consisting of a context token length of 0 and a Wrap token The entity that sends the first Wrap token will have to specify a bitmap of supported and preferred quality of protection schemes The entity that replies to the Wrap tokens will pick a scheme based on the bitmask and local policy The quality of protection values are defined in section 9 Two pairs of input formats to the GS2 Wrap function are defined The first pair is used when the client sends the Wrap token first and the server responds The other pair is used when the server sends the Josefsson Expires August 10 2007 Page 11 Internet Draft SASL GS2 February 2007 Wrap token first and the client responds The inputs below are passed to GS2 Wrap and the output is used as the Wrap token value Some fields in the input formats are optional indicated by brackets and and explained by the text below 4 3 1 The GS2 Wrap function The GS2 Wrap function have two implementations and which one is used depends on whether the negotiated GSS API context supports per message protection When a context is successfully negotiated i e when GSS S COMPLETE is returned from for clients GSS Init sec context or for servers GSS Accept sec context and the output variable integ avail is FALSE then GSS Wrap cannot be used and instead we define GS2 Wrap to be the identity function When integ avail is negotiated TRUE the GS2 Wrap is identical to calling the GSS Wrap function with conf flag set to FALSE and using the generated output message as the output data 4 3 2 Client first GS2 Wrap input The input to GS2 Wrap when the client sends a Wrap token field first 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 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 channel binding length client cbqops channel binding data authzid The client qops integer indicate the client s preferred quality of protection if channel bindings are absent or the negotiation of the 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 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 Josefsson Expires August 10 2007 Page 12 Internet Draft SASL GS2 February 2007 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 indicate the length of the channel binding data field The optional field client cbqops is present only if channel binding length is non zero and indicate the client s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 5 The authorization identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 4 3 3 Server last GS2 Wrap input The input to GS2 Wrap when the server sends a Wrap token field after 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 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 The server qop field integer indicate the selected quality of protection The quality of protection values are defined in section 9 The server maxbuf field indicate the maximum protected data buffer size the server can receive in network byte order It MUST be 0 if 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 3 4 Server first GS2 Wrap input The input to GS2 Wrap when the server sends the Wrap token first is as follows Josefsson Expires August 10 2007 Page 13 Internet Draft SASL GS2 February 2007 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 server qops server maxbuf server cbqops channel binding data The server qops field is an integer indicating the server s preferred quality of protection if channel bindings are absent or the 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 optional field server cbqops indicate the server s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data contain the actual channel binding data 4 3 5 Client last GS2 Wrap input The input to GS2 Wrap when the clients sends a Wrap token field 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 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 authzid 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 Josefsson Expires August 10 2007 Page 14 Internet Draft SASL GS2 February 2007 5 Channel Bindings The GS2 mechanism provide its own channel binding mechanism instead of using the chan binding parameter in the GSS API context functions The reason for this is that the GS2 mechanism 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 do not match Client and servers MUST set the chan binding parameter in the calls to GSS Init sec context and GSS Accept sec context respectively to NULL Implementations SHOULD set the client cbqops and server cbqops to no security layer and instead depend on the session security afforded by the bound in channel Use of no SASL security layers in combination with channel binding should provide better performance than using SASL security layers over secure channels and better security characteristics than using no SASL security layers over secure channels without channel binding For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see 7 Josefsson Expires August 10 2007 Page 15 Internet Draft SASL GS2 February 2007 6 Protocol Overview This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur An informal pseudo language is used to describe the packets sent below GS2 Wrap refer to the operation of calling GS2 Wrap on the indicated fields formatted in the structures described earlier GSS Init sec context and GSS Accept sec context refer to the context token generated by calling the respective function The GS2 SASL Message is denoted as Context token Wrap token and the length fields are not mentioned An authentication exchange using GS2 may look like C Request authentication exchange S Send token C Send GSS Init sec context token S After PROT READY is set send GSS Accept sec context GS2 Wrap server qops server maxbuf C After PROT READY is set send GSS Init sec context GS2 Wrap client qop client maxbuf authzid S Send GSS Accept sec context token C Send GSS Init sec context token S Outcome of authentication exchange 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 when the protocol profile does not support additional information to be sent together with the authentication request The next example illustrate when the client sends its Wrap token first Josefsson Expires August 10 2007 Page 16 Internet Draft SASL GS2 February 2007 C Request authentication exchange S Send token C Send GSS Init sec context token C After PROT READY is set send GSS Init sec context GS2 Wrap client qops client maxbuf channel binding length 0 authzid S After PROT READY is set send GSS Accept sec context GS2 Wrap server qop server maxbuf C Send GSS Init sec context token S Send GSS Accept sec context token S Outcome of authentication exchange If the protocol profile support the optional initial client response the first empty message can be optimized away and then the protocol exchange will look like C Request authentication exchange and send GSS Init sec context token S Send GSS Accept sec context token S Outcome of authentication exchange If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol exchange will look like C Request authentication exchange and send GSS Init sec context token S Send GSS Accept sec context token C Send GSS Init sec context token S Indicate successful authentication and send GSS Accept sec context token as additional information If the PROT READY flag is never set by the GSS API mechanism the GS2 Wrap message will be sent after the context has been established The protocol may look like Josefsson Expires August 10 2007 Page 17 Internet Draft SASL GS2 February 2007 C Request authentication exchange S GSS Accept sec context returns GSS S COMPLETE and outputs a token send GS2 Wrap server qops server maxbuf C GSS Init sec context returns GSS S COMPLETE and does not output a token send GS2 Wrap client qop client maxbuf channel binding length 0 authzid S Outcome of authentication exchange Alternatively if the client finishes first it may look like C Request authentication exchange C GSS Init sec context returns GSS S COMPLETE and outputs a token send GS2 Wrap client qops client maxbuf channel binding length 0 authzid S GSS Accept sec context returns GSS S COMPLETE and does not output a token send GS2 Wrap server qop server maxbuf channel binding length 0 S Outcome of authentication exchange Adding channel bindings to the last examples gives the following complex 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 GSS Init sec context GS2 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 GS2 Wrap server qop server maxbuf channel binding length 0 S Outcome of authentication exchange If the protocol support initial data from the client and the 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 client when indicating successful authentication the following protocol exchange will occur Josefsson Expires August 10 2007 Page 18 Internet Draft SASL GS2 February 2007 C Request authentication exchange and send GSS Init sec context GS2 Wrap client qops client maxbuf channel binding length 0 authzid token S Indicate successful authentication and send GSS Accept sec context GS2 Wrap server qop server maxbuf token as additional information The last example illustrate the optimal round trip wise authentication possible using this protocol Josefsson Expires August 10 2007 Page 19 Internet Draft SASL GS2 February 2007 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received i e length shorter than 4 octets o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Unwrap returns anything other than GSS S COMPLETE There can t be supplementary status codes in GS2 at this point so any indications of out of order processing or replays is fatal o The token returned from GSS Unwrap fail to parse correctly e g too short invalid maximum buffer size as the expected Wrap token o Local policy reject the attempt For example client and server can t agree on qop proposal o server side Authorization of client principal i e src name in GSS Acecpt sec context to requested authzid failed Josefsson Expires August 10 2007 Page 20 Internet Draft SASL GS2 February 2007 8 GSS API Parameters The implementation MAY set any GSSAPI flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy Josefsson Expires August 10 2007 Page 21 Internet Draft SASL GS2 February 2007 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

    Original URL path: http://www.josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-06.txt (2016-04-30)
    Open archived version from archive


  • 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 Josefsson Expires July 13 2007 Page 10 Internet Draft SASL GS2 January 2007 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 MUST examine 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 GS2 Wrap function is defined below and its inputs 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 GSS Accept sec context the flag is implied by successful context negotiation This is for GSS API v1 mechanisms that do not support PROT READY or for GSS API mechanism that do not provide per message protection This may result in a SASL token consisting of a context token length of 0 and a Wrap token The entity that sends the first Wrap token will have to specify a bitmap of supported and preferred quality of protection schemes The entity that replies to the Wrap tokens will pick a scheme based on the bitmask and local policy The quality of protection values are defined in section 9 Two pairs of input formats to the GS2 Wrap function are defined The first pair is used when the client sends the Wrap token first and the server responds The other pair is used when the server sends the Josefsson Expires July 13 2007 Page 11 Internet Draft SASL GS2 January 2007 Wrap token first and the client responds The inputs below are passed to GS2 Wrap and the output is used as the Wrap token value Some fields in the input formats are optional indicated by brackets and and explained by the text below 4 3 1 The GS2 Wrap function The GS2 Wrap function have two implementations and which one is used depends on whether the negotiated GSS API context supports per message protection When a context is successfully negotiated i e when GSS S COMPLETE is returned from for clients GSS Init sec context or for servers GSS Accept sec context and the output variable integ avail is FALSE then GSS Wrap cannot be used and instead we define GS2 Wrap to be the identity function When integ avail is negotiated TRUE the GS2 Wrap is identical to calling the GSS Wrap function with conf flag set to FALSE and using the generated output message as the output data 4 3 2 Client first GS2 Wrap input The input to GS2 Wrap when the client sends a Wrap token field first 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 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 channel binding length client cbqops channel binding data authzid The client qops integer indicate the client s preferred quality of protection if channel bindings are absent or the negotiation of the 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 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 Josefsson Expires July 13 2007 Page 12 Internet Draft SASL GS2 January 2007 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 indicate the length of the channel binding data field The optional field client cbqops is present only if channel binding length is non zero and indicate the client s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 5 The authorization identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 4 3 3 Server last GS2 Wrap input The input to GS2 Wrap when the server sends a Wrap token field after 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 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 The server qop field integer indicate the selected quality of protection The quality of protection values are defined in section 9 The server maxbuf field indicate the maximum protected data buffer size the server can receive in network byte order It MUST be 0 if 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 3 4 Server first GS2 Wrap input The input to GS2 Wrap when the server sends the Wrap token first is as follows Josefsson Expires July 13 2007 Page 13 Internet Draft SASL GS2 January 2007 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 server qops server maxbuf server cbqops channel binding data The server qops field is an integer indicating the server s preferred quality of protection if channel bindings are absent or the 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 optional field server cbqops indicate the server s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data contain the actual channel binding data 4 3 5 Client last GS2 Wrap input The input to GS2 Wrap when the clients sends a Wrap token field 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 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 authzid 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 Josefsson Expires July 13 2007 Page 14 Internet Draft SASL GS2 January 2007 5 Channel Bindings The GS2 mechanism provide its own channel binding mechanism instead of using the chan binding parameter in the GSS API context functions The reason for this is that the GS2 mechanism 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 do not match Client and servers MUST set the chan binding parameter in the calls to GSS Init sec context and GSS Accept sec context respectively to NULL Implementations SHOULD set the client cbqops and server cbqops to no security layer and instead depend on the session security afforded by the bound in channel Use of no SASL security layers in combination with channel binding should provide better performance than using SASL security layers over secure channels and better security characteristics than using no SASL security layers over secure channels without channel binding For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see 7 Josefsson Expires July 13 2007 Page 15 Internet Draft SASL GS2 January 2007 6 Protocol Overview This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur An informal pseudo language is used to describe the packets sent below GS2 Wrap refer to the operation of calling GS2 Wrap on the indicated fields formatted in the structures described earlier GSS Init sec context and GSS Accept sec context refer to the context token generated by calling the respective function The GS2 SASL Message is denoted as Context token Wrap token and the length fields are not mentioned An authentication exchange using GS2 may look like C Request authentication exchange S Send token C Send GSS Init sec context token S After PROT READY is set send GSS Accept sec context wrap length GS2 Wrap server qops server maxbuf C After PROT READY is set send GSS Init sec context wrap length GS2 Wrap client qop client maxbuf authzid S Send GSS Accept sec context token C Send GSS Init sec context token S Outcome of authentication exchange 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 when the protocol profile does not support additional information to be sent together with the authentication request The next example illustrate when the client sends its Wrap token first Josefsson Expires July 13 2007 Page 16 Internet Draft SASL GS2 January 2007 C Request authentication exchange S Send token C Send GSS Init sec context token C After PROT READY is set send GSS Init sec context GS2 Wrap client qops client maxbuf channel binding length 0 authzid S After PROT READY is set send GSS Accept sec context GS2 Wrap server qop server maxbuf C Send GSS Init sec context token S Send GSS Accept sec context token S Outcome of authentication exchange If the protocol profile support the optional initial client response the first empty message can be optimized away and then the protocol exchange will look like C Request authentication exchange and send GSS Init sec context token S Send GSS Accept sec context token S Outcome of authentication exchange If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol exchange will look like C Request authentication exchange and send GSS Init sec context token S Send GSS Accept sec context token C Send GSS Init sec context token S Indicate successful authentication and send GSS Accept sec context token as additional information If the PROT READY flag is never set by the GSS API mechanism the GS2 Wrap message will be sent after the context has been established The protocol may look like Josefsson Expires July 13 2007 Page 17 Internet Draft SASL GS2 January 2007 C Request authentication exchange S GSS Accept sec context returns GSS S COMPLETE and outputs a token send GS2 Wrap server qops server maxbuf C GSS Init sec context returns GSS S COMPLETE and does not output a token send GS2 Wrap client qop client maxbuf channel binding length 0 authzid S Outcome of authentication exchange Alternatively if the client finishes first it may look like C Request authentication exchange C GSS Init sec context returns GSS S COMPLETE and outputs a token send GS2 Wrap client qops client maxbuf channel binding length 0 authzid S GSS Accept sec context returns GSS S COMPLETE and does not output a token send GS2 Wrap server qop server maxbuf channel binding length 0 S Outcome of authentication exchange Adding channel bindings to the last examples gives the following complex 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 GSS Init sec context GS2 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 GS2 Wrap server qop server maxbuf channel binding length 0 S Outcome of authentication exchange If the protocol support initial data from the client and the 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 client when indicating successful authentication the following protocol exchange will occur Josefsson Expires July 13 2007 Page 18 Internet Draft SASL GS2 January 2007 C Request authentication exchange and send GSS Init sec context GS2 Wrap client qops client maxbuf channel binding length 0 authzid token S Indicate successful authentication and send GSS Accept sec context GS2 Wrap server qop server maxbuf token as additional information The last example illustrate the optimal round trip wise authentication possible using this protocol Josefsson Expires July 13 2007 Page 19 Internet Draft SASL GS2 January 2007 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received i e length shorter than 4 octets o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Unwrap returns anything other than GSS S COMPLETE There can t be supplementary status codes in GS2 at this point so any indications of out of order processing or replays is fatal o The token returned from GSS Unwrap fail to parse correctly e g too short invalid maximum buffer size as the expected Wrap token o Local policy reject the attempt For example client and server can t agree on qop proposal o server side Authorization of client principal i e src name in GSS Acecpt sec context to requested authzid failed Josefsson Expires July 13 2007 Page 20 Internet Draft SASL GS2 January 2007 8 GSS API Parameters The implementation MAY set any GSSAPI flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy Josefsson Expires July 13 2007 Page 21 Internet Draft SASL GS2 January 2007 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

    Original URL path: http://www.josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-05.txt (2016-04-30)
    Open archived version from archive


  • the client expect the server to issue a token in a subsequent challenge or as additional information to the outcome of the authentication The client pass the context token to another call to GSS Init sec context repeating the procedure until GSS S COMPLETE is returned or authentication is aborted Josefsson Expires June 10 2007 Page 9 Internet Draft SASL GS2 December 2006 If the server sent a non empty Wrap token the context token is processed before processing the other tokens This is required because GSS Unwrap may need the context to be in the state it is after the Context token in the message has been processed When GSS Init sec context returns GSS S COMPLETE the client MUST examine the context to ensure that it provides a level of protection permitted by the client s security policy 4 2 2 Server side The server passes the first context token to GSS Accept sec context as input token setting input context handle to GSS C NO CONTEXT initially the chan binding set to NULL and a suitable acceptor cred handle see below Servers SHOULD use a credential obtained by calling GSS Acquire cred 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 Josefsson Expires June 10 2007 Page 10 Internet Draft SASL GS2 December 2006 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 MUST examine 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 GSS Accept sec context the flag is implied by successful context 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 token length of 0 and a Wrap token The entity that sends its first Wrap token will have to specify a bitmap of supported and preferred quality of protection schemes The entity that replies to the Wrap tokens will pick a scheme based on the bitmask and local policy The quality of protection values are defined in section 9 Two pairs of input formats to the GSS Wrap function are defined The first pair is used when the client sends the GSS Wrap token first and the server responds The other pair is used when the server sends the GSS Wrap token first and the client responds Josefsson Expires June 10 2007 Page 11 Internet Draft SASL GS2 December 2006 The inputs below are passed to GSS Wrap with conf flag set to FALSE and the Wrap token will be the generated output message Some fields in the input formats are optional indicated by brackets and and explained by the text below 4 3 1 Client first GSS Wrap input The input to GSS Wrap when the client sends a Wrap token field first 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 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 channel binding length client cbqops channel binding data authzid The client qops integer indicate the client s preferred quality of protection if channel bindings are absent or the negotiation of the 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 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 indicate the length of the channel binding data field The optional field client cbqops is present only if channel binding length is non zero and indicate the client s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data Josefsson Expires June 10 2007 Page 12 Internet Draft SASL GS2 December 2006 The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 5 The authorization identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 4 3 2 Server last GSS Wrap input The input to GSS Wrap when the server sends a Wrap token field after 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 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 The server qop field integer indicate the selected quality of protection The quality of protection values are defined in section 9 The server maxbuf field indicate the maximum protected data buffer size the server can receive in network byte order It MUST be 0 if 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 3 3 Server first GSS Wrap input The input to GSS Wrap when the server sends the Wrap token first 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 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 cbqops channel binding data The server qops field is an integer indicating the server s preferred quality of protection if channel bindings are absent or the negotiation of the channel binding fails The quality of protection values are defined in section 9 The server maxbuf is the same as above Josefsson Expires June 10 2007 Page 13 Internet Draft SASL GS2 December 2006 The optional field server cbqops indicate the server s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data contain the actual channel binding data 4 3 4 Client last GSS Wrap input The input to GSS Wrap when the clients sends a Wrap token field 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 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 authzid 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 Josefsson Expires June 10 2007 Page 14 Internet Draft SASL GS2 December 2006 5 Channel Bindings The GS2 mechanism provide its own channel binding mechanism instead of using the chan binding parameter in the GSS API context functions The reason for this is that the GS2 mechanism 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 do not match Client and servers MUST set the chan binding parameter in the calls to GSS Init sec context and GSS Accept sec context respectively to NULL Implementations SHOULD set the client cbqops and server cbqops to no security layer and instead depend on the session security afforded by the bound in channel Use of no SASL security layers in combination with channel binding should provide better performance than using SASL security layers over secure channels and better security characteristics than using no SASL security layers over secure channels without channel binding For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see 7 Josefsson Expires June 10 2007 Page 15 Internet Draft SASL GS2 December 2006 6 Protocol Overview This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are 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 C Request authentication exchange S Send length 0 token C Send length GSS Init sec context token S After PROT READY is set send length GSS Accept sec context GSS Wrap server qops server maxbuf C After PROT READY is set send length GSS Init sec context GSS Wrap client qop client maxbuf authzid S Send length GSS Accept sec context token C Send length GSS Init sec context token S Outcome of authentication exchange 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 when the protocol profile does not support additional information to be sent together with the authentication request The next example illustrate when the client sends its Wrap token first Josefsson Expires June 10 2007 Page 16 Internet Draft SASL GS2 December 2006 C Request authentication exchange S Send length 0 token C Send length GSS Init sec context token C After PROT READY is set send length GSS Init sec context GSS Wrap client qops client maxbuf channel binding length 0 authzid S After PROT READY is set send length GSS Accept sec context GSS Wrap server qop server maxbuf C Send length GSS Init sec context token S Send length GSS Accept sec context token S Outcome of authentication exchange If the protocol profile support the optional initial client response the first empty message can be optimized away and then the protocol exchange will look like C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token S Outcome of authentication exchange If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol exchange will look like C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token C Send length GSS Init sec context token S Indicate successful authentication and send length GSS Accept sec context token as additional information 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 The protocol may look like Josefsson Expires June 10 2007 Page 17 Internet Draft SASL GS2 December 2006 C Request authentication exchange S GSS Accept sec context returns GSS S COMPLETE and outputs a token send length context token GSS Wrap server qops server maxbuf C GSS Init sec context returns GSS S COMPLETE and does not output a token send length 0 context token GSS Wrap client qop client maxbuf channel binding length 0 authzid S Outcome of authentication exchange Alternatively if the client finishes first it may look like 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 client maxbuf channel binding length 0 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 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 S Outcome of authentication exchange If the protocol support initial data from the client and the 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 Josefsson Expires June 10 2007 Page 18 Internet Draft SASL GS2 December 2006 client when indicating successful authentication the following protocol exchange will occur C Request authentication exchange and send length GSS Init sec context GSS Wrap client qops client maxbuf channel binding length 0 authzid token S Indicate successful authentication and send length GSS Accept sec context GSS Wrap server qop server maxbuf token as additional information The last example illustrate the optimal round trip wise authentication possible using this protocol Josefsson Expires June 10 2007 Page 19 Internet Draft SASL GS2 December 2006 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received i e length shorter than 4 octets o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Unwrap returns anything other than GSS S COMPLETE There can t be supplementary status codes in GS2 at this point so any indications of out of order processing or replays is fatal o The token returned from GSS Unwrap fail to parse correctly e g too short invalid maximum buffer size as the expected Wrap token o Local policy reject the attempt For example client and server can t agree on qop proposal o server side Authorization of client principal i e src name in GSS Acecpt

    Original URL path: http://www.josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-04.txt (2016-04-30)
    Open archived version from archive


  • handle see below Servers SHOULD use a credential obtained by calling GSS Acquire cred 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 Josefsson Expires April 26 2007 Page 7 Internet Draft SASL GS2 October 2006 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 GSS Accept sec context the flag is implied by successful context 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 token length of 0 and a Wrap token The entity that sends its first Wrap token will have to specify a bitmap of supported and preferred quality of protection schemes The entity that replies to the Wrap tokens will pick a scheme based on the bitmask and local policy The quality of protection values are defined in section 9 Two pairs of input formats to the GSS Wrap function are defined The first pair is used when the client sends the GSS Wrap token first and the server responds The other pair is used when the server sends the GSS Wrap token first and the client responds The inputs below are passed to GSS Wrap with conf flag set to FALSE and the Wrap token will be the generated output message Some fields in the input formats are optional indicated by brackets and and explained by the text below Josefsson Expires April 26 2007 Page 8 Internet Draft SASL GS2 October 2006 4 3 1 Client first GSS Wrap input The input to GSS Wrap when the client sends a Wrap token field first 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 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 channel binding length client cbqops channel binding data authzid The client qops integer indicate the client s preferred quality of protection if channel bindings are absent or the negotiation of the 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 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 indicate the length of the channel binding data field The optional field client cbqops is present only if channel binding length is non zero and indicate the client s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 6 The authorization identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 Josefsson Expires April 26 2007 Page 9 Internet Draft SASL GS2 October 2006 4 3 2 Server last GSS Wrap input The input to GSS Wrap when the server sends a Wrap token field after 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 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 The server qop field integer indicate the selected quality of protection The quality of protection values are defined in section 9 The server maxbuf field indicate the maximum protected data buffer size the server can receive in network byte order It MUST be 0 if 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 3 3 Server first GSS Wrap input The input to GSS Wrap when the server sends the Wrap token first 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 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 cbqops channel binding data The server qops field is an integer indicating the server s preferred quality of protection if channel bindings are absent or the 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 optional field server cbqops indicate the server s preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 Josefsson Expires April 26 2007 Page 10 Internet Draft SASL GS2 October 2006 The optional field channel binding data contain the actual channel binding data 4 3 4 Client last GSS Wrap input The input to GSS Wrap when the clients sends a Wrap token field 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 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 authzid 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 5 Channel Bindings The GS2 mechanism provide its own channel binding mechanism instead of using the chan binding parameter in the GSS API context functions The reason for this is that the GS2 mechanism 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 do not match Client and servers MUST set the chan binding parameter in the calls to GSS Init sec context and GSS Accept sec context respectively to NULL Implementations SHOULD set the client cbqops and server cbqops to no security layer and instead depend on the session security afforded by the bound in channel Use of no SASL security layers in combination with channel binding should provide better performance than using SASL security layers over secure channels and better security characteristics than using no SASL security layers over secure channels without channel binding For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see 7 Josefsson Expires April 26 2007 Page 11 Internet Draft SASL GS2 October 2006 6 Protocol Overview This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are 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 C Request authentication exchange S Send length 0 token C Send length GSS Init sec context token S After PROT READY is set send length GSS Accept sec context GSS Wrap server qops server maxbuf C After PROT READY is set send length GSS Init sec context GSS Wrap client qop client maxbuf authzid S Send length GSS Accept sec context token C Send length GSS Init sec context token S Outcome of authentication exchange 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 when the protocol profile does not support additional information to be sent together with the authentication request The next example illustrate when the client sends its Wrap token first Josefsson Expires April 26 2007 Page 12 Internet Draft SASL GS2 October 2006 C Request authentication exchange S Send length 0 token C Send length GSS Init sec context token C After PROT READY is set send length GSS Init sec context GSS Wrap client qops client maxbuf channel binding length 0 authzid S After PROT READY is set send length GSS Accept sec context GSS Wrap server qop server maxbuf C Send length GSS Init sec context token S Send length GSS Accept sec context token S Outcome of authentication exchange If the protocol profile support the optional initial client response the first empty message can be optimized away and then the protocol exchange will look like C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token S Outcome of authentication exchange If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol exchange will look like C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token C Send length GSS Init sec context token S Indicate successful authentication and send length GSS Accept sec context token as additional information 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 The protocol may look like Josefsson Expires April 26 2007 Page 13 Internet Draft SASL GS2 October 2006 C Request authentication exchange S GSS Accept sec context returns GSS S COMPLETE and outputs a token send length context token GSS Wrap server qops server maxbuf C GSS Init sec context returns GSS S COMPLETE and does not output a token send length 0 context token GSS Wrap client qop client maxbuf channel binding length 0 authzid S Outcome of authentication exchange Alternatively if the client finishes first it may look like 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 client maxbuf channel binding length 0 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 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 S Outcome of authentication exchange If the protocol support initial data from the client and the 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 Josefsson Expires April 26 2007 Page 14 Internet Draft SASL GS2 October 2006 client when indicating successful authentication the following protocol exchange will occur C Request authentication exchange and send length GSS Init sec context GSS Wrap client qops client maxbuf channel binding length 0 authzid token S Indicate successful authentication and send length GSS Accept sec context GSS Wrap server qop server maxbuf token as additional information The last example illustrate the optimal round trip wise authentication possible using this protocol 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received i e length shorter than 4 octets o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Unwrap returns anything other than GSS S COMPLETE There can t be supplementary status codes in GS2 at this point so any indications of out of order processing or replays is fatal o The token returned from GSS Unwrap fail to parse correctly e g too short invalid maximum buffer size as the expected Wrap token o Local policy reject the attempt For example client and server can t agree on qop proposal o server side Authorization of client principal i e src name in GSS Acecpt sec context to requested authzid failed 8 GSS API Parameters The implementation MAY set any GSSAPI flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy 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 Josefsson Expires April 26 2007 Page 15 Internet Draft SASL GS2 October 2006 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 1 No security layer 2 Integrity protection Sender calls GSS Wrap with conf flag set to FALSE 4 Confidentiality protection Sender calls GSS Wrap with conf flag set to TRUE Other bit masks may be

    Original URL path: http://www.josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-03.txt (2016-04-30)
    Open archived version from archive


  • additional information to the outcome of the authentication The client pass the context token to another call to GSS Init sec context repeating the actions in this paragraph until GSS S COMPLETE is returned or authentication is aborted If the Josefsson Expires January 14 2007 Page 5 Internet Draft SASL GS2 July 2006 server supply data beyond the context token the context token is processed first and then the overflow data is passed to GSS Unwrap and the unwrapped data 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 as input token setting input context handle to 0 initially mech type of the GSSAPI mechanism for which this SASL mechanism is registered the chan binding set to NULL 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 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 is processed first and then the overflow data is passed to GSS Unwrap and the unwrapped data interpreted During the authentication exchange the server will generate one Wrap token using GSS Wrap 4 3 Wrap Token The Wrap token MUST NOT be sent before the PROT READY flag has been 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 GSS Wrap token does not have to be sent directly when the PROT READY flag is set During any exchange exactly one GSS Wrap token is sent in each direction The input to 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 server the authentication MUST fail If PROT READY is never set by GSS Init sec context or GSS Accept sec context the flag is implied by successful context 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 token length of 0 and a Wrap token The entity that sends its first Wrap token will have to specify a bitmap of supported and preferred quality of protection schemes The entity that reply to the Wrap tokens will pick a scheme based on the bitmask and local policy Four input formats to the GSS Wrap function are defined The first two input formats are used when the client sends the GSS Wrap token Josefsson Expires January 14 2007 Page 6 Internet Draft SASL GS2 July 2006 first and the server reponds The other two input formats are used when the server sends the GSS Wrap token first and the client responds The input formats below are passed to GSS Wrap with conf flag set to FALSE and the Wrap token output will be the generated output message Some fields in the input formats are optional indicated by brackets and and explained by the text below 4 3 1 GSS Wrap input for client requests The input to GSS Wrap when the client sends the GSS Wrap token first 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 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 channel binding length client cbqops channel binding data authzid The client qops integer indicate the client s preferred quality of protection if channel bindings are absent or the negotiation of the channel binding fails The client maxbuf field indicate the maximum protected buffer size the client can receive The channel binding length is a network byte order integer that indicate the length of the channel binding data field The optional field client cbqops is present only if channel binding length is non zero and indicate the client s preferred quality of protection if channel binding negotiation succeeds The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data The optional field authzid contain the authorization identity The Josefsson Expires January 14 2007 Page 7 Internet Draft SASL GS2 July 2006 authorization identity is encoded using UTF 8 6 The authorization identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 4 3 2 GSS Wrap input for server responses The data format for input to GSS Wrap when the server responds to the previous GSS Wrap token data 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 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 The server qop field integer indicate the selected quality of protection The server maxbuf field indicate the maximum data buffer size the server can receive It MUST be 0 if the server doesn t advertise support for any security layer the client MUST verify this 4 3 3 GSS Wrap input for server requests The data format for input to GSS Wrap when the server sends the GSS Wrap token first 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 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 channel binding length server cbqops channel binding data The server qops field is an integer indicating the server s preferred quality of protection if channel bindings are absent or the negotiation of the channel binding fails The server maxbuf is the same as above The channel binding length is a network byte order integer that indicate the length of the channel binding data field The optional field server cbqops is present only if channel binding length is non zero and indicate the server s Josefsson Expires January 14 2007 Page 8 Internet Draft SASL GS2 July 2006 preferred quality of protection if channel binding negotiation succeeds The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data 4 3 4 GSS Wrap input for client responses The data format for input to GSS Wrap when the client responds to the previous token 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 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 authzid The client qop field is the selected quality of protection The client maxbuf and authzid fields are as above 5 Channel Bindings The GS2 mechanism provide its own channel binding mechanism instead of using the chan binding parameter in the GSS API context functions The reason for this is that the GS2 mechanism 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 Client and servers MUST set the chan binding parameter in the calls to GSS Init sec context to GSS Accept sec context respectively to NULL Implementations SHOULD set the client cbqops and server cbqops to no security layer and instead depend on the session security afforded by the bound in channel Use of no SASL security layers in combination with channel binding should provide better performance than using SASL security layers over secure channels and better security characteristics than using no SASL security layers over secure channels without channel binding For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see 7 Josefsson Expires January 14 2007 Page 9 Internet Draft SASL GS2 July 2006 6 Protocol Overview This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur An authentication exchange using GS2 may look like C Request authentication exchange S Send length 0 token C Send length GSS Init sec context token S After PROT READY is set send length GSS Accept sec context GSS Wrap server qops server maxbuf channel binding length 0 C After PROT READY is set send length GSS Init sec context GSS Wrap client qop client maxbuf authzid S Send length GSS Accept sec context token C Send length GSS Init sec context token S Outcome of authentication exchange 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 when the protocol profile do not support additional information to be sent together with the authentication request The next example illustrate when the client sends its Wrap token first Josefsson Expires January 14 2007 Page 10 Internet Draft SASL GS2 July 2006 C Request authentication exchange S Send length 0 token C Send length GSS Init sec context token C After PROT READY is set send length GSS Init sec context GSS Wrap client qops client maxbuf channel binding length 0 authzid S After PROT READY is set send length GSS Accept sec context GSS Wrap server qop server maxbuf C Send length GSS Init sec context token S Send length GSS Accept sec context token S Outcome of authentication exchange If the protocol profile support the optional initial client response the first empty message can be optimized away and then the protocol exchange will look like C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token S Outcome of authentication exchange If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol exchange will look like C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token C Send length GSS Init sec context token S Indicate successful authentication and send length GSS Accept sec context token as additional information 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 The protocol may look like Josefsson Expires January 14 2007 Page 11 Internet Draft SASL GS2 July 2006 C Request authentication exchange S GSS Accept sec context returns GSS S COMPLETE and outputs a token send length context token GSS Wrap server qops server maxbuf channel binding length 0 C GSS Init sec context returns GSS S COMPLETE and does not output a token send length 0 context token GSS Wrap client qop client maxbuf channel binding length 0 authzid S Outcome of authentication exchange Alternatively if the client finishes first it may look like 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 client maxbuf channel binding length 0 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 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 S Outcome of authentication exchange If the protocol support initial data from the client and the PROT READY flag is set in the client after the first call to Josefsson Expires January 14 2007 Page 12 Internet Draft SASL GS2 July 2006 GSS Init sec context and the server can send additional data to the client when indicating successful authentication the following protocol exchange will occur C Request authentication exchange and send length GSS Init sec context GSS Wrap client qops client maxbuf channel binding length 0 authzid token S Indicate successful authentication and send length GSS Accept sec context GSS Wrap server qop server maxbuf token as additional information The last example illustrate the optimal round trip wise authentication possible using this protocol 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received i e length shorter than 4 octets o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Unwrap returns anything other than GSS S COMPLETE There can t be supplementary status codes in GS2 at this point so any indications of out of order processing or replays is fatal o The token returned from GSS Unwrap fail to parse correctly e g too short invalid maximum buffer size as the expected Wrap token o Local policy reject the attempt For example client and server can t agree on qop proposal o server side Authorization of client principal i e src name in GSS Acecpt sec context to requested authzid failed 8 GSS API Parameters The implementation MAY set any GSSAPI flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy 9 Security Layer Bits The security layers and their corresponding bit masks are as follows Josefsson Expires January 14 2007 Page 13 Internet Draft SASL GS2 July 2006 1 No security layer 2 Integrity protection Sender calls GSS Wrap with conf flag set to FALSE 4 Confidentiality protection Sender calls GSS Wrap with conf flag set to TRUE Other bit masks may be defined in the future bits which are not understood MUST be negotiated off Note that SASL 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 9 1 Examples 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 integrity is negotiated the octet will encode an integer 4 as follows 0 1 2 3 4 5 6 7 0 0 0 0 0 0 1 1 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 Josefsson Expires January 14 2007 Page 14 Internet Draft SASL GS2 July 2006 10 1 The interoperability problem If a client or server only support Kerberos V5 under the GSSAPI name and the server or client only support Kerberos V5 under the GS2 family the authentication negotiation will fail 10 2 Resolving the problem If the Kerberos V5 mechanism is supported under GS2 in a server the server SHOULD also support Kerberos V5 through the GSSAPI mechanism to avoid interoperability problems with older clients Reasons for violating this recommendation may include security considerations regarding the absent features in the GS2 mechanism The Kerberos V5 GSSAPI SASL mechanism lack channel bindings which could enable certain tunnel attacks 17 10 3 Additional recommendations It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism rather than through the GSSAPI mechanism if both are available because of the additional features in the GS2 mechanism 11 Mechanisms that negotiate other mechanisms A GSS API mechanism that negotiate other mechanisms interact badly with the SASL mechanism negotiation There are two problems The first is an interoperability problem and the second is a security concern The problems are described and resolved below 11 1 The interoperability problem If a client implement GSS API mechanism X potentially negotiated through a GSS API mechanism Y and the server also implement GSS API mechanism X negotiated through a GSS API mechanism Z the authentication negotiation will fail 11 2 Security problem If a client s policy is to first prefer GSSAPI mechanism X then non

    Original URL path: http://www.josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-02.txt (2016-04-30)
    Open archived version from archive


  • the client should expect the server to issue a token in a subsequent challenge or as additional information to the outcome of the authentication The client must pass the context token to another call to GSS Init sec context repeating the actions in this paragraph until GSS S COMPLETE is returned or authentication is aborted If the 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 as input token setting input context handle to 0 initially mech type of the GSSAPI mechanism for which this SASL mechanism is registered the chan binding set to NULL or the channel binding data 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 Josefsson Expires December 28 2006 Page 6 Internet Draft SASL GS2 June 2006 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 The Wrap token MUST NOT be sent before the PROT READY flag has been 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 GSS Wrap token does not have to be sent directly when the PROT READY flag is set During any exchange exactly one GSS Wrap token is sent in each direction The input to 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 server the authentication MUST fail If PROT READY is never set by GSS Init sec context or GSS Accept sec context the flag is implied by successful context 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 token length of 0 and a Wrap token The entity that sends its first Wrap token will have to specify a bitmap of supported and preferred quality of protection schemes The entity that reply to the Wrap tokens will pick a scheme based on the bitmask and local policy Four input formats to the GSS Wrap function are defined The first two input formats are used when the client sends the GSS Wrap token first and the server reponds The other two input formats are used when the server sends the GSS Wrap token first and the client responds The input formats below are passed to GSS Wrap with conf flag set to FALSE and the Wrap token output will be the generated output message Some fields in the input formats are optional indicated by brackets and and explained by the text below 4 4 1 Wrap Token Input For Client Requests The input to GSS Wrap when the client sends the GSS Wrap token first is as follows Josefsson Expires December 28 2006 Page 7 Internet Draft SASL GS2 June 2006 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 client qops client maxbuf channel binding length client cbqops channel binding data authzid The client qops integer indicate the client s preferred quality of protection if channel bindings are absent or the negotiation of the channel binding fails The client maxbuf field indicate the maximum protected buffer size the client can receive The channel binding length is a network byte order integer that indicate the length of the channel binding data field The optional field client cbqops is present only if channel binding length is non zero and indicate the client s preferred quality of protection if channel binding negotiation succeeds The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 6 The authorization identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 4 4 2 WraP Token Input For Server Responses The data format for input to GSS Wrap when the server responds to the previous GSS Wrap token data 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 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 The server qop field integer indicate the selected quality of Josefsson Expires December 28 2006 Page 8 Internet Draft SASL GS2 June 2006 protection The server maxbuf field indicate the maximum data buffer size the server can receive It MUST be 0 if the server doesn t advertise support for any security layer the client MUST verify this 4 4 3 Wrap Token Input For Server Requests The data format for input to GSS Wrap when the server sends the GSS Wrap token first 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 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 channel binding length server cbqops channel binding data The server qops field is an integer indicating the server s preferred quality of protection if channel bindings are absent or the negotiation of the channel binding fails The server maxbuf is the same as above The channel binding length is a network byte order integer that indicate the length of the channel binding data field 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 channel binding length is non zero and contain the actual channel binding data 4 4 4 Wrap Token Input For Client Responses The data format for input to GSS Wrap when the client responds to the previous token is as follows Josefsson Expires December 28 2006 Page 9 Internet Draft SASL GS2 June 2006 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 client qop client maxbuf authzid The client qop field is the selected quality of protection The client maxbuf and authzid fields are as above 5 Channel Bindings This section is tentative further discussion on the topic This was written to provide an example of how the details of how one approach to this concept could look like There are other approaches that may be preferable The GS2 mechanism provide its own token field for channel bindings 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 Josefsson Expires December 28 2006 Page 10 Internet Draft SASL GS2 June 2006 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 string TLS channel binding and based on the master secret and the random values established during a TLS handshake a 64 octet string that make up the SASL channel binding data Using the terminology of TLS 13 the channel binding data is computed as follows SASL channel binding PRF SecurityParameters master secret TLS channel binding SecurityParameters server random SecurityParameters client random 0 64 The derived data is intended to be used as a name of the TLS channel that is cryptographically bound to the channel for use in authentication mechanisms tunneled over TLS 6 Protocol Overview This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur An authentication exchange using GS2 may look like Josefsson Expires December 28 2006 Page 11 Internet Draft SASL GS2 June 2006 C Request authentication exchange S Send length 0 token C Send length GSS Init sec context token S After PROT READY is set send length GSS Accept sec context GSS Wrap server qops server maxbuf channel binding length 0 C After PROT READY is set send length GSS Init sec context GSS Wrap client qop client maxbuf authzid S Send length GSS Accept sec context token C Send length GSS Init sec context token S Outcome of authentication exchange 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 when the protocol profile do not support additional information to be sent together with the authentication request The next example illustrate when the client sends its Wrap token first C Request authentication exchange S Send length 0 token C Send length GSS Init sec context token C After PROT READY is set send length GSS Init sec context GSS Wrap client qops client maxbuf channel binding length 0 authzid S After PROT READY is set send length GSS Accept sec context GSS Wrap server qop server maxbuf C Send length GSS Init sec context token S Send length GSS Accept sec context token S Outcome of authentication exchange If the protocol profile support the optional initial client response the first empty message can be optimized away and then the protocol exchange will look like Josefsson Expires December 28 2006 Page 12 Internet Draft SASL GS2 June 2006 C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token S Outcome of authentication exchange If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol exchange will look like C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token C Send length GSS Init sec context token S Indicate successful authentication and send length GSS Accept sec context token as additional information 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 The protocol may look like C Request authentication exchange S GSS Accept sec context returns GSS S COMPLETE and outputs a token send length context token GSS Wrap server qops server maxbuf channel binding length 0 C GSS Init sec context returns GSS S COMPLETE and does not output a token send length 0 context token GSS Wrap client qop client maxbuf channel binding length 0 authzid S Outcome of authentication exchange Alternatively if the client finishes first it may look like 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 client maxbuf channel binding length 0 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 Josefsson Expires December 28 2006 Page 13 Internet Draft SASL GS2 June 2006 S Outcome of authentication exchange If the protocol support initial data from the client and the 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 client when indicating successful authentication the following protocol exchange will occur C Request authentication exchange and send length GSS Init sec context GSS Wrap client qops client maxbuf channel binding length 0 authzid token S Indicate successful authentication and send length GSS Accept sec context GSS Wrap server qop server maxbuf token as additional information The last example illustrate the optimal round trip wise authentication possible using this protocol 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received i e length shorter than 4 octets o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Unwrap returns anything other than GSS S COMPLETE There can t be supplementary status codes in GS2 at this point so any indications of out of order processing or replays should be fatal o The token returned from GSS Unwrap fail to parse correctly e g too short invalid maximum buffer size as the expected Wrap token o Local policy reject the attempt For example client and server can t agree on qop proposal o server side Authorization of client principal i e src name in GSS Acecpt sec context to requested authzid failed 8 GSS API Parameters The implementation MAY set any GSSAPI flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy Josefsson Expires December 28 2006 Page 14 Internet Draft SASL GS2 June 2006 9 Security Layer Bits The security layers and their corresponding bit masks are as follows 1 No security layer 2 Integrity protection Sender calls GSS Wrap with conf flag set to FALSE 4 Confidentiality protection Sender calls GSS Wrap with conf flag set to TRUE Other bit masks may be defined in the future bits which are not understood must be negotiated off Note that SASL 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 10 Interoperability With The Gssapi Mechanism The GSSAPI mechanism 11 describe how the Kerberos V5 GSS API 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 If a client or server only support Kerberos V5 under the GSSAPI name and the server or client only support Kerberos V5 under the GS2 family the

    Original URL path: http://www.josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-01.txt (2016-04-30)
    Open archived version from archive



  •