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".

  • 12 01 02 02 The SHA 1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 93 25 51 6a fc ff 04 b0 43 60 Convert the 7 octets to binary drop the last bit and re group them in groups of 5 and convert them back to decimal which results in these computations hex 82 d2 73 25 76 6b d6 binary 10000010 11010010 01110011 00100101 01110110 01101011 1101011 binary in groups of 5 10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011 decimal of each group 16 11 9 7 6 9 11 22 13 15 11 base32 encoding Q L J H G J L W N P L The last step translates each decimal value using table 3 in Base32 RFC4648 Thus the SASL mechanism name for the Kerberos V5 GSSAPI mechanism would be GS2 QLJHGJLWNPL and because this mechanism supports channel binding GS2 QLJHGJLWNPL PLUS Instead the next section assigns the Kerberos V5 mechanism a non hash derived mechanism name 3 4 Grandfathered mechanism names Some older GSS API mechanisms were not specified with a SASL GS2 mechanism name Using a shorter name can be useful nonetheless We specify the names GS2 KRB5 and GS2 KRB5 PLUS for the Kerberos V5 mechanism to be used as if the original specification documented it See Section 15 4 SASL Authentication Exchange Message Format During the SASL authentication exchange for GS2 a number of messages following the following format is sent between the client and server On success this number is the same as the number of context tokens that the GSS API mechanism would normally require in order to establish a security context On failures the exchange can be terminated early by any party Josefsson Williams Expires July 12 2010 Page 7 Internet Draft SASL GS2 January 2010 When using a GS2 mechanism the SASL client is always a GSS API initiator and the SASL server is always a GSS API acceptor The client calls GSS Init sec context and the server calls GSS Accept sec context All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for the initial security context token The client and server MAY send GSS API error tokens tokens output by GSS Init sec context or GSS Accept sec context when the major status code is other than GSS S COMPLETE or GSS S CONTINUE NEEDED As this indicates an error condition after sending the token the sending side should fail the authentication The initial security context token is modified as follows o The initial context token header see section 3 1 of RFC2743 MUST be removed if present If the header is not present the client MUST send a gs2 nonstd flag flag see below On the server side this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context except when the gs2 nonstd flag is sent o A GS2 header MUST be prefixed to the resulting initial context token This header has the form gs2 header given below in ABNF RFC5234 The figure below describes the permissible attributes their use and the format of their values All attribute names are single US ASCII letters and are case sensitive Josefsson Williams Expires July 12 2010 Page 8 Internet Draft SASL GS2 January 2010 UTF8 1 safe x01 2B x2D 3C x3E 7F As UTF8 1 in RFC 3629 except NUL and UTF8 2 UTF8 3 UTF8 4 UTF8 char safe UTF8 1 safe UTF8 2 UTF8 3 UTF8 4 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname GS2 has to transport an authzid since the GSS API has no equivalent gs2 nonstd flag F F means the mechanism is not a standard GSS API mechanism in that the RFC2743 section 3 1 header was missing cb name 1 ALPHA DIGIT See RFC 5056 section 7 gs2 cb flag p cb name n y GS2 channel binding CB flag p client supports and used CB n client does not support CB y client supports CB thinks the server does not gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid The GS2 header is gs2 header When the gs2 nonstd flag flag is present the client did not find remove a token header RFC2743 section 3 1 from the initial token returned by GSS Init sec context This signals to the server that it MUST NOT re add the data that is normally removed by the client The gs2 cb flag signals the channel binding mode One of p n or y is used A p means the client supports and used a channel binding and the name of the channel binding type is indicated A n means that the client does not support channel binding A y means the client supports channel binding but believes the server does not support it so it did not use a channel binding See the next section for more details The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 RFC3629 with three exceptions o The NUL character is forbidden as required by section 3 4 1 of RFC4422 o The server MUST replace any comma in the string with 2C o The server MUST replace any equals in the string with 3D Upon receipt of this value the server verifies its correctness according to the used SASL protocol profile Failed verification Josefsson Williams Expires July 12 2010 Page 9 Internet Draft SASL GS2 January 2010 results in a failed authentication exchange 5 Channel Bindings GS2 supports channel binding to external secure channels such as TLS Clients and servers may or may not support channel binding therefore the use of channel binding is negotiable GS2 does not provide security layers however therefore it is imperative that GS2 provide integrity protection for the negotiation of channel binding Use of channel binding is negotiated as follows o Servers SHOULD advertise both non PLUS and the PLUS variant of each GS2 mechanism name If the server cannot support channel binding it MAY advertise only the non PLUS variant If the server would never succeed authentication of the non PLUS variant due to policy reasons it MAY advertise only the PLUS variant o If the client negotiates mechanisms then clients MUST select the PLUS variant if offered by the server Otherwise the client does not negotiate mechanisms if the client has no prior knowledge about mechanisms supported by the server and wasn t explicitly configured to use a particular variant of the GS2 mechanism then it MUST select only non PLUS version of the GS2 mechanism o If the client does not support channel binding then it MUST use a n gs2 cb flag o If the client supports channel binding and the server does not appear to i e the client did not see the PLUS name then the client MUST either fail authentication or it MUST chose the non PLUS mechanism name and use a y gs2 cb flag o If the client supports channel binding and the server appears to support it i e the client see the PLUS name or if the client wishes to use channel binding but the client does not negotiate mechanisms then the client MUST use a p gs2 cb flag to indicate the channel binding type it is using o The client generate the chan bindings input parameter for GSS Init sec context as described below o Upon receipt of the initial authentication message the server checks the gs2 cb flag in the GS2 header and constructs a chan bindings parameter for GSS Accept sec context as described below If the client channel binding flag was y and the server did advertise support for channel bindings then the server MUST fail authentication If the client channel binding flag was p and the server does not support the indicated channel binding type then the server MUST fail authentication Josefsson Williams Expires July 12 2010 Page 10 Internet Draft SASL GS2 January 2010 FLAG SERVER CB SUPPORT DISPOSITION n Irrelevant If server disallows non channel bound authentication then fail y CB not supported Authentication may succeed y CB supported Authentication must fail p CB supported Authentication may succeed with CB used p CB not supported Authentication will fail CB not supported Client does not even try because it insists on CB For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 5 1 Content of GSS CHANNEL BINDINGS structure The calls to GSS Init sec context and GSS Accept sec context take a chan bindings parameter The value is a GSS CHANNEL BINDINGS structure RFC5554 The initiator address type and acceptor address type fields of the GSS CHANNEL BINDINGS structure MUST be set to 0 The initiator address and acceptor address fields MUST be the empty string The application data field MUST be set to the gs2 header concatenated with when a gs2 cb flag of p is used the application s channel binding data 5 2 Default Channel Binding A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows tls unique is the default channel binding type for any application that doesn t specify one Servers MUST implement the tls unique tls unique I D altman tls channel bindings channel binding type if they implement any channel binding Clients SHOULD implement the tls unique channel binding type if they implement any channel binding Josefsson Williams Expires July 12 2010 Page 11 Internet Draft SASL GS2 January 2010 Clients and servers SHOULD choose the highest layer innermost end to end TLS channel as the channel to bind to Servers MUST choose the channel binding type indicated by the client or fail authentication if they don t support it 6 Examples Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given C Request authentication exchange S Empty Challenge C n a someuser S Send reply context token as is C Empty message S Outcome of authentication exchange Example 2 a one and one half round trip GSS API context token exchange no channel binding C Request authentication exchange S Empty Challenge C n S Send reply context token as is C Send reply context token as is S Outcome of authentication exchange Example 3 a two round trip GSS API context token exchange no channel binding no standard token header C Request authentication exchange S Empty Challenge C F n S Send reply context token as is C Send reply context token as is S Send reply context token as is C Empty message S Outcome of authentication exchange Josefsson Williams Expires July 12 2010 Page 12 Internet Draft SASL GS2 January 2010 Example 4 using channel binding optional authzid given C Request authentication exchange S Empty Challenge C p tls unique a someuser S Send reply context token as is Example 5 using channel binding C Request authentication exchange S Empty Challenge C p tls unique S Send reply context token as is Example 6 using non standard channel binding requires out of band negotiation C Request authentication exchange S Empty Challenge C p tls server end point S Send reply context token as is Example 7 client supports channel bindings but server does not optional authzid given C Request authentication exchange S Empty Challenge C y a someuser S Send reply context token as is GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See section 3 of RFC4422 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following Josefsson Williams Expires July 12 2010 Page 13 Internet Draft SASL GS2 January 2010 conditions are true o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o If the client s initial GS2 header does not match the ABNF o In particular if the initial character of the client message is anything except F p n or y o If the client s GS2 channel binding flag was y and the server supports channel bindings o If the client s GS2 channel binding flag was p and the server does not support the indicated channel binding o If the client requires use of channel binding and the server did not advertise support for channel binding o Authorization of client principal i e src name in GSS Accept sec context to requested authzid failed o If the client is not authorized to the requested authzid or an authzid could not be derived from the client s initiator principal name 8 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the per message token ret flags from GSS Init sec context and GSS Accept sec context are irrelevant implementations SHOULD NOT set the per message req flags The mutual req flag MUST be set If channel binding is used then the client MUST check that the corresponding ret flag is set when the context is fully establish else authentication MUST fail Use or non use of deleg req flag and anon req flag is an implementation specific detail SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them SASL and GS2 implementors are encouraged to provide programming interfaces which provide a good mapping of GSS API naming options 9 Naming There s no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor principal names see RFC2743 section 4 1 and clients will typically have username initiator principal names see RFC2743 section 4 2 When a host based acceptor principal name is used service hostname service is the service name specified in the protocol s profile and hostname is the fully qualified host name Josefsson Williams Expires July 12 2010 Page 14 Internet Draft SASL GS2 January 2010 of the server 10 GSS Inquire SASLname for mech call We specify a new GSS API utility function to allow SASL implementations to more efficiently identify the GSS API mechanism that a particular SASL mechanism name refers to Inputs o desired mech OBJECT IDENTIFIER Outputs o sasl mech name UTF 8 STRING SASL name for this mechanism caller must release with GSS Release buffer o mech name UTF 8 STRING name of this mechanism possibly localized caller must release with GSS Release buffer o mech description UTF 8 STRING possibly localized description of this mechanism caller must release with GSS Release buffer Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that a desired mech was unsupported by the GSS API implementation The GSS Inquire SASLname for mech call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in user friendly form The output variable sasl mech name will hold the IANA registered mechanism name for the GSS API mechanism or if none is registered a mechanism name computed from the OID as described in section 3 1 of this document Josefsson Williams Expires July 12 2010 Page 15 Internet Draft SASL GS2 January 2010 10 1 gss inquire saslname for mech The C binding for the GSS Inquire SASLname for mech call is as follows OM uint32 gss inquire saslname for mech OM uint32 minor status const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description Purpose Output the SASL mechanism name of a GSS API mechanism It also returns a name and description of the mechanism in a user friendly form Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 11 GSS Inquire mech for SASLname call To allow SASL clients to more efficiently identify which GSS API mechanism a particular SASL mechanism name refers to we specify a new GSS API utility function for this purpose Josefsson Williams Expires July 12 2010 Page 16 Internet Draft SASL GS2 January 2010 Inputs o sasl mech name UTF 8 STRING SASL name of mechanism Outputs o mech type OBJECT IDENTIFIER must be explicit mechanism and not default specifier Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that no supported GSS API mechanism had the indicated sasl mech name The GSS Inquire mech for SASLname call is used to get the GSS API mechanism OID associated with a SASL mechanism name Josefsson Williams Expires July 12 2010 Page 17 Internet Draft SASL GS2 January 2010 11 1 gss inquire mech for saslname The C binding for the GSS Inquire mech for SASLname call is as follows OM uint32 gss inquire mech for saslname OM uint32 minor status const gss buffer t sasl mech name gss OID mech type Purpose Output GSS API mechanism OID of mechanism associated with given sasl mech name Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 12 Security Layers GS2 does not support SASL security layers Applications that need integrity or confidentiality protection can use either channel binding to a secure external channel or another SASL mechanism that does provide security layers 13 Interoperability

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



  • GS2 DT4PIK22T6A The OID for the Kerberos V5 GSS API mechanism RFC1964 is 1 2 840 113554 1 2 2 and its DER encoding is in hex 06 09 2A 86 48 86 F7 12 01 02 02 The SHA 1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 93 25 51 6a fc ff 04 b0 43 60 Convert the 7 octets to binary drop the last bit and re group them in groups of 5 and convert them back Josefsson Williams Expires May 13 2010 Page 6 Internet Draft SASL GS2 November 2009 to decimal which results in these computations hex 82 d2 73 25 76 6b d6 binary 10000010 11010010 01110011 00100101 01110110 01101011 1101011 binary in groups of 5 10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011 decimal of each group 16 11 9 7 6 9 11 22 13 15 11 base32 encoding Q L J H G J L W N P L The last step translate each decimal value using table 3 in Base32 RFC4648 Thus the SASL mechanism name for the Kerberos V5 GSSAPI mechanism would be GS2 QLJHGJLWNPL and because this mechanism supports channel binding GS2 QLJHGJLWNPL PLUS Instead the next section assigns the Kerberos V5 mechanism a non hash derived mechanism name 3 4 Grandfathered mechanism names Some older GSS API mechanisms were not specified with a SASL GS2 mechanism name Using a shorter name can be useful nonetheless We specify the names GS2 KRB5 and GS2 KRB5 PLUS for the Kerberos V5 mechanism to be used as if the original specification documented it See Section 15 4 SASL Authentication Exchange Message Format During the SASL authentication exchange for GS2 a number of messages following the following format is sent between the client and server On success this number is the same as the number of context tokens that the GSS API mechanism would normally require in order to establish a security context On failures the exchange can be terminated early by any party When using a GS2 mechanism the SASL client is always a GSS API initiator and the SASL server is always a GSS API acceptor The client calls GSS Init sec context and the server calls GSS Accept sec context Josefsson Williams Expires May 13 2010 Page 7 Internet Draft SASL GS2 November 2009 All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for the initial security context token The client and server MAY send GSS API error tokens tokens output by GSS Init sec context or GSS Accept sec context when the major status code is other than GSS S COMPLETE or GSS S CONTINUE NEEDED As this indicate an error condition after sending the token the sending side should fail the authentication The initial security context token is modified as follows o The RFC2743 section 3 1 initial context token header MUST be removed if present If the header is not present the client MUST send a gs2 nonstd flag flag see below On the server side this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context except when the gs2 nonstd flag is sent o A GS2 header MUST be prefixed to the resulting initial context token This header has the form gs2 header given below in ABNF RFC5234 The figure below describes the permissible attributes their use and the format of their values All attribute names are single US ASCII letters and are case sensitive Josefsson Williams Expires May 13 2010 Page 8 Internet Draft SASL GS2 November 2009 UTF8 1 safe x01 2B x2D 3C x3E 7F As UTF8 1 in RFC 3629 except NUL and UTF8 2 UTF8 3 UTF8 4 UTF8 char safe UTF8 1 safe UTF8 2 UTF8 3 UTF8 4 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname GS2 has to transport an authzid since the GSS API has no equivalent gs2 nonstd flag F F means the mechanism is not a standard GSS API mechanism in that the RFC2743 section 3 1 header was missing cb name 1 ALPHA DIGIT See RFC 5056 section 7 gs2 cb flag p cb name n y GS2 channel binding CB flag p client supports and used CB n client does not support CB y client supports CB thinks the server does not gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid The GS2 header is gs2 header When the gs2 nonstd flag flag is present the client did not find remove a RFC2743 section 3 1 token header from the initial token returned by GSS Init sec context This signals to the server that it MUST NOT re add the data that is normally removed by the client The gs2 cb flag signals the channel binding mode One of p n or y is used A p means the client supports and used a channel binding and the name of the channel binding type is indicated A n means that the client does not support channel binding A y means the client supports channel binding but believes the server does not support it so it did not use a channel binding See the next section for more details The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 RFC3629 with three exceptions o The NUL characters is forbidden as required by section 3 4 1 of RFC4422 o The server MUST replace any comma in the string with 2C o The server MUST replace any equals in the string with 3D Upon the receipt of this value the server verifies its correctness according to the used SASL protocol profile Failed verification Josefsson Williams Expires May 13 2010 Page 9 Internet Draft SASL GS2 November 2009 results in failed authentication exchange 5 Channel Bindings GS2 supports channel binding to external secure channels such as TLS Clients and servers may or may not support channel binding therefore the use of channel binding is negotiable GS2 does not provide security layers however therefore it is imperative that GS2 provide integrity protection for the negotiation of channel binding Use of channel binding is negotiated as follows o Servers SHOULD advertise both non PLUS and the PLUS variant of each GS2 mechanism name If the server cannot support channel binding it MAY advertise only the non PLUS variant If the server would never succeed authentication of the non PLUS variant due to policy reasons it MAY advertise only the PLUS variant o If the client negotiates mechanisms then clients MUST select the PLUS variant if offered by the server Otherwise the client does not negotiate mechanisms if the client has no prior knowledge about mechanisms supported by the server and wasn t explicitly configured to use a particular variant of the GS2 mechanism then it MUST select only non PLUS version of the GS2 mechanism o If the client does not support channel binding then it MUST use a n gs2 cb flag o If the client supports channel binding and the server does not appear to i e the client did not see the PLUS name then the client MUST either fail authentication or it MUST chose the non PLUS mechanism name and use a y gs2 cb flag o If the client supports channel binding and the server appears to support it i e the client see the PLUS name or if the client wishes to use channel binding but the client does not negotiate mechanisms then the client MUST use a p gs2 cb flag to indicate the channel binding type it is using o The client generate the chan bindings input parameter for GSS Init sec context as described below o Upon receipt of the initial authentication message the server checks the gs2 cb flag in the GS2 header and constructs a chan bindings parameter for GSS Accept sec context as described below If the client channel binding flag was y and the server did advertise support for channel bindings then the server MUST fail authentication If the client channel binding flag was p and the server does not support the indicated channel binding type then the server MUST fail authentication For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 Josefsson Williams Expires May 13 2010 Page 10 Internet Draft SASL GS2 November 2009 5 1 Content of GSS CHANNEL BINDINGS structure The calls to GSS Init sec context and GSS Accept sec context takes a chan bindings parameter The value is a GSS CHANNEL BINDINGS structure RFC5554 The initiator address type and acceptor address type fields of the GSS CHANNEL BINDINGS structure MUST be set to 0 The initiator address and acceptor address fields MUST be the empty string The application data field MUST be set to the gs2 header concatenated with when a gs2 cb flag of p is used the application s channel binding data 5 2 Default Channel Binding A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows tls unique is the default channel binding type for any application that doesn t specify one Servers MUST implement the tls unique tls unique I D altman tls channel bindings channel binding type if they implement any channel binding Clients SHOULD implement the tls unique channel binding type if they implement any channel binding Clients and servers SHOULD choose the highest layer innermost end to end TLS channel as the channel to bind to Servers MUST choose the channel binding type indicated by the client or fail authentication if they don t support it 6 Examples Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given C Request authentication exchange S Empty Challenge C n a someuser S Send reply context token as is C Empty message S Outcome of authentication exchange Josefsson Williams Expires May 13 2010 Page 11 Internet Draft SASL GS2 November 2009 Example 2 a one and one half round trip GSS API context token exchange no channel binding C Request authentication exchange S Empty Challenge C n S Send reply context token as is C Send reply context token as is S Outcome of authentication exchange Example 3 a two round trip GSS API context token exchange no channel binding no standard token header C Request authentication exchange S Empty Challenge C F n S Send reply context token as is C Send reply context token as is S Send reply context token as is C Empty message S Outcome of authentication exchange Example 4 using channel binding optional authzid given C Request authentication exchange S Empty Challenge C p tls unique a someuser S Send reply context token as is Example 5 using channel binding C Request authentication exchange S Empty Challenge C p tls unique S Send reply context token as is Josefsson Williams Expires May 13 2010 Page 12 Internet Draft SASL GS2 November 2009 Example 6 using non standard channel binding requires out of band negotiation C Request authentication exchange S Empty Challenge C p tls server end point S Send reply context token as is Example 7 client supports channel bindings but server does not optional authzid given C Request authentication exchange S Empty Challenge C y a someuser S Send reply context token as is GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See section 3 of RFC4422 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o If the client s initial GS2 header does not match the ABNF o In particular if the initial character of the client message is anything except F p n or y o If the client s GS2 channel binding flag was y and the server supports channel bindings o If the client s GS2 channel binding flag was p and the server does not support the indicated channel binding o If the client requires use of channel binding and the server did not advertise support for channel binding o Authorization of client principal i e src name in GSS Accept sec context to requested authzid failed o If the client is not authorized to the requested authzid or an authzid could not be derived from the client s initiator principal name Josefsson Williams Expires May 13 2010 Page 13 Internet Draft SASL GS2 November 2009 8 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the setting of req flags related to per message tokens is irrelevant The mutual req flag MUST be set If channel binding is used then the client MUST check that the corresponding ret flag is set when the context is fully establish else authentication MUST fail Use or non use of deleg req flag and anon req flag is an implementation specific detail SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them SASL and GS2 implementors are encouraged to provide programming interfaces which provide a good mapping of GSS API naming options 9 Naming There s no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor principal names see RFC2743 section 4 1 and clients will typically have username initiator principal names see RFC2743 section 4 2 When a host based acceptor principal name is used service hostname service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server 10 GSS Inquire SASLname for mech call To allow SASL implementations to query for the SASL mechanism name of a GSS API mechanism we specify a new GSS API function for this purpose Josefsson Williams Expires May 13 2010 Page 14 Internet Draft SASL GS2 November 2009 Inputs o desired mech OBJECT IDENTIFIER Outputs o sasl mech name UTF 8 STRING SASL name for this mechanism caller must release with GSS Release buffer o mech name UTF 8 STRING name of this mechanism possibly localized caller must release with GSS Release buffer o mech description UTF 8 STRING possibly localized description of this mechanism caller must release with GSS Release buffer Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that a desired mech was unsupported by the GSS API implementation The GSS Inquire SASLname for mech call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in user friendly form The output variable sasl mech name will hold the IANA registered mechanism name for the GSS API mechanism or if none is registered a mechanism name computed from the OID as described in section 3 1 of this document Josefsson Williams Expires May 13 2010 Page 15 Internet Draft SASL GS2 November 2009 10 1 gss inquire saslname for mech The C binding for the GSS Inquire SASLname for mech call is as follows OM uint32 gss inquire saslname for mech OM uint32 minor status const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description Purpose Output the SASL mechanism name of a GSS API mechanism It also returns a name and description of the mechanism in a user friendly form Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 11 GSS Inquire mech for SASLname call To allow SASL clients to more efficiently identify which GSS API mechanism a particular SASL mechanism name refers to we specify a new GSS API utility function for this purpose Josefsson Williams Expires May 13 2010 Page 16 Internet Draft SASL GS2 November 2009 Inputs o sasl mech name UTF 8 STRING SASL name of mechanism Outputs o mech type OBJECT IDENTIFIER must be explicit mechanism and not default specifier Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that no supported GSS API mechanism had the indicated sasl mech name The GSS Inquire mech for SASLname call is used to get the GSS API mechanism OID associated with a SASL mechanism name Josefsson Williams Expires May 13 2010 Page 17 Internet Draft SASL GS2 November 2009 11 1 gss inquire mech for saslname The C binding for the GSS Inquire mech for SASLname call is as follows OM uint32 gss inquire mech for saslname OM uint32 minor status const gss buffer t sasl mech name gss OID mech type Purpose Output GSS API mechanism OID of mechanism associated with given sasl mech name Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 12 Security Layers GS2 does not support SASL security layers Applications that need integrity or confidentiality protection can use either channel binding to a secure external channel or another SASL mechanism that does provide security layers 13 Interoperability with the SASL GSSAPI mechanism The Kerberos V5 GSS API RFC1964 mechanism is currently used in SASL under the name GSSAPI see GSSAPI mechanism RFC4752 The Kerberos V5 mechanism

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


  • 00000 decimal of each group 3 19 28 15 8 10 26 26 19 30 0 base32 encoding D T 4 P I K 2 2 T 6 A The last step translate each decimal value using table 3 in Base32 RFC4648 Thus the SASL mechanism name for the SPKM 1 GSSAPI mechanism is GS2 DT4PIK22T6A The OID for the Kerberos V5 GSS API mechanism RFC1964 is 1 2 840 113554 1 2 2 and its DER encoding is in hex 06 09 2A 86 48 86 F7 12 01 02 02 The SHA 1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 93 25 51 6a fc ff 04 b0 43 60 Convert the 7 octets to binary drop the last bit and re group them in groups of 5 and convert them back Josefsson Williams Expires March 13 2010 Page 6 Internet Draft SASL GS2 September 2009 to decimal which results in these computations hex 82 d2 73 25 76 6b d6 binary 10000010 11010010 01110011 00100101 01110110 01101011 1101011 binary in groups of 5 10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011 decimal of each group 16 11 9 7 6 9 11 22 13 15 11 base32 encoding Q L J H G J L W N P L The last step translate each decimal value using table 3 in Base32 RFC4648 Thus the SASL mechanism name for the Kerberos V5 GSSAPI mechanism would be GS2 QLJHGJLWNPL and because this mechanism supports channel binding GS2 QLJHGJLWNPL PLUS Instead the next section assigns the Kerberos V5 mechanism a non hash derived mechanism name 3 4 Grandfathered mechanism names Some older GSS API mechanisms were not specified with a SASL GS2 mechanism name Using a shorter name can be useful nonetheless We specify the names GS2 KRB5 and GS2 KRB5 PLUS for the Kerberos V5 mechanism to be used as if the original specification documented it See Section 15 4 SASL Authentication Exchange Message Format During the SASL authentication exchange for GS2 a number of messages following the following format is sent between the client and server On success this number is the same as the number of context tokens that the GSS API mechanism would normally require in order to establish a security context On failures the exchange can be terminated early by any party When using a GS2 mechanism the SASL client is always a GSS API initiator and the SASL server is always a GSS API acceptor The client calls GSS Init sec context and the server calls GSS Accept sec context Josefsson Williams Expires March 13 2010 Page 7 Internet Draft SASL GS2 September 2009 All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for the initial security context token The client and server MAY send GSS API error tokens tokens output by GSS Init sec context or GSS Accept sec context when the major status code is other than GSS S COMPLETE or GSS S CONTINUE NEEDED As this indicate an error condition after sending the token the sending side should fail the authentication The initial security context token is modified as follows o The RFC2743 section 3 1 initial context token header MUST be removed if present If the header is not present the client MUST send a gs2 nonstd flag flag see below On the server side this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context except when the gs2 nonstd flag is sent o A GS2 header MUST be prefixed to the resulting initial context token This header has the form gs2 header given below in ABNF RFC5234 UTF8 1 safe x01 2B x2D 3C x3E 7F As UTF8 1 in RFC 3629 except NUL and UTF8 2 UTF8 3 UTF8 4 UTF8 char safe UTF8 1 safe UTF8 2 UTF8 3 UTF8 4 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname GS2 has to transport an authzid since the GSS API has no equivalent gs2 nonstd flag F F means the mechanism is not a standard GSS API mechanism in that the RFC2743 section 3 1 header was missing cb name 1 ALPHA DIGIT See RFC 5056 section 7 gs2 cb flag p cb name n y GS2 channel binding CB flag p client supports and used CB n client does not support CB y client supports CB thinks the server does not gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid The GS2 header is gs2 header Josefsson Williams Expires March 13 2010 Page 8 Internet Draft SASL GS2 September 2009 When the gs2 nonstd flag flag is present the client did not find remove a RFC2743 section 3 1 token header from the initial token returned by GSS Init sec context This signals to the server that it MUST NOT re add the data that is normally removed by the client The gs2 cb flag signals the channel binding mode One of p n or y is used A p means the client supports and used a channel binding and the name of the channel binding type is indicated A n means that the client does not support channel binding A y means the client supports channel binding but believes the server does not support it so it did not use a channel binding See the next section for more details The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 RFC3629 with three exceptions o The NUL characters is forbidden as required by section 3 4 1 of RFC4422 o The server MUST replace any comma in the string with 2C o The server MUST replace any equals in the string with 3D Upon the receipt of this value the server verifies its correctness according to the used SASL protocol profile Failed verification results in failed authentication exchange 5 Channel Bindings GS2 supports channel binding to external secure channels such as TLS Clients and servers may or may not support channel binding therefore the use of channel binding is negotiable GS2 does not provide security layers however therefore it is imperative that GS2 provide integrity protection for the negotiation of channel binding Use of channel binding is negotiated as follows o Servers SHOULD advertise both non PLUS and the PLUS variant of each GS2 mechanism name If the server cannot support channel binding it MAY advertise only the non PLUS variant If the server would never succeed authentication of the non PLUS variant due to policy reasons it MAY advertise only the PLUS variant o If the client negotiates mechanisms then clients MUST select the PLUS variant if offered by the server Otherwise the client does not negotiate mechanisms if the client has no prior knowledge about mechanisms supported by the server and wasn t explicitly configured to use a particular variant of the GS2 mechanism then it MUST select only non PLUS version of the GS2 mechanism o If the client does not support channel binding then it MUST use a n gs2 cb flag Josefsson Williams Expires March 13 2010 Page 9 Internet Draft SASL GS2 September 2009 o If the client supports channel binding and the server does not appear to i e the client did not see the PLUS name then the client MUST either fail authentication or it MUST chose the non PLUS mechanism name and use a y gs2 cb flag o If the client supports channel binding and the server appears to support it i e the client see the PLUS name or if the client wishes to use channel binding but the client does not negotiate mechanisms then the client MUST use a p gs2 cb flag to indicate the channel binding type it is using o The client generate the chan bindings input parameter for GSS Init sec context as described below o Upon receipt of the initial authentication message the server checks the gs2 cb flag in the GS2 header and constructs a chan bindings parameter for GSS Accept sec context as described below If the client channel binding flag was y and the server did advertise support for channel bindings then the server MUST fail authentication If the client channel binding flag was p and the server does not support the indicated channel binding type then the server MUST fail authentication For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 5 1 Content of GSS CHANNEL BINDINGS structure The calls to GSS Init sec context and GSS Accept sec context takes a chan bindings parameter The value is a GSS CHANNEL BINDINGS structure RFC5554 The initiator address type and acceptor address type fields of the GSS CHANNEL BINDINGS structure MUST be set to 0 The initiator address and acceptor address fields MUST be the empty string The application data field MUST be set to the gs2 header concatenated with when a gs2 cb flag of p is used the application s channel binding data 5 2 Default Channel Binding A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows tls unique is the default channel binding type for any application that doesn t specify one Servers MUST implement the tls unique tls unique I D altman tls channel bindings channel binding type if they Josefsson Williams Expires March 13 2010 Page 10 Internet Draft SASL GS2 September 2009 implement any channel binding Clients SHOULD implement the tls unique channel binding type if they implement any channel binding Clients and servers SHOULD choose the highest layer innermost end to end TLS channel as the channel to bind to Servers MUST choose the channel binding type indicated by the client or fail authentication if they don t support it 6 Examples Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given C Request authentication exchange S Empty Challenge C n a someuser S Send reply context token as is C Empty message S Outcome of authentication exchange Example 2 a one and one half round trip GSS API context token exchange no channel binding C Request authentication exchange S Empty Challenge C n S Send reply context token as is C Send reply context token as is S Outcome of authentication exchange Example 3 a two round trip GSS API context token exchange no channel binding no standard token header C Request authentication exchange S Empty Challenge C F n S Send reply context token as is C Send reply context token as is S Send reply context token as is C Empty message S Outcome of authentication exchange Josefsson Williams Expires March 13 2010 Page 11 Internet Draft SASL GS2 September 2009 Example 4 using channel binding optional authzid given C Request authentication exchange S Empty Challenge C p tls unique a someuser S Send reply context token as is Example 5 using channel binding C Request authentication exchange S Empty Challenge C p tls unique S Send reply context token as is Example 6 using non standard channel binding requires out of band negotiation C Request authentication exchange S Empty Challenge C p tls server end point S Send reply context token as is Example 7 client supports channel bindings but server does not optional authzid given C Request authentication exchange S Empty Challenge C y a someuser S Send reply context token as is GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See section 3 of RFC4422 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following Josefsson Williams Expires March 13 2010 Page 12 Internet Draft SASL GS2 September 2009 conditions are true o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o If the client s initial GS2 header does not match the ABNF o In particular if the initial character of the client message is anything except F p n or y o If the client s GS2 channel binding flag was y and the server supports channel bindings o If the client s GS2 channel binding flag was p and the server does not support the indicated channel binding o If the client requires use of channel binding and the server did not advertise support for channel binding o Authorization of client principal i e src name in GSS Accept sec context to requested authzid failed o If the client is not authorized to the requested authzid or an authzid could not be derived from the client s initiator principal name 8 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the setting of req flags related to per message tokens is irrelevant 9 Naming There s no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor principal names see RFC2743 section 4 1 and clients will typically have username initiator principal names see RFC2743 section 4 2 When a host based acceptor principal name is used service hostname service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server 10 GSS Inquire SASLname for mech call To allow SASL implementations to query for the SASL mechanism name of a GSS API mechanism we specify a new GSS API function for this purpose Josefsson Williams Expires March 13 2010 Page 13 Internet Draft SASL GS2 September 2009 Inputs o desired mech OBJECT IDENTIFIER Outputs o sasl mech name UTF 8 STRING SASL name for this mechanism caller must release with GSS Release buffer o mech name UTF 8 STRING name of this mechanism possibly localized caller must release with GSS Release buffer o mech description UTF 8 STRING possibly localized description of this mechanism caller must release with GSS Release buffer Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that a desired mech was unsupported by the GSS API implementation The GSS Inquire SASLname for mech call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in user friendly form The output variable sasl mech name will hold the IANA registered mechanism name for the GSS API mechanism or if none is registered a mechanism name computed from the OID as described in section 3 1 of this document Josefsson Williams Expires March 13 2010 Page 14 Internet Draft SASL GS2 September 2009 10 1 gss inquire saslname for mech The C binding for the GSS Inquire SASLname for mech call is as follows OM uint32 gss inquire saslname for mech OM uint32 minor status const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description Purpose Output the SASL mechanism name of a GSS API mechanism It also returns a name and description of the mechanism in a user friendly form Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 11 GSS Inquire mech for SASLname call To allow SASL clients to more efficiently identify which GSS API mechanism a particular SASL mechanism name refers to we specify a new GSS API utility function for this purpose Josefsson Williams Expires March 13 2010 Page 15 Internet Draft SASL GS2 September 2009 Inputs o sasl mech name UTF 8 STRING SASL name of mechanism Outputs o mech type OBJECT IDENTIFIER must be explicit mechanism and not default specifier Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that no supported GSS API mechanism had the indicated sasl mech name The GSS Inquire mech for SASLname call is used to get the GSS API mechanism OID associated with a SASL mechanism name Josefsson Williams Expires March 13 2010 Page 16 Internet Draft SASL GS2 September 2009 11 1 gss inquire mech for saslname The C binding for the GSS Inquire mech for SASLname call is as follows OM uint32 gss inquire mech for saslname OM uint32 minor status const gss buffer t sasl mech name gss OID mech type Purpose Output GSS API mechanism OID of mechanism associated with given sasl mech name Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 12 Security Layers GS2 does not support SASL security layers Applications that need integrity or confidentiality protection can use either channel binding to a secure external channel or another SASL mechanism that does provide security layers 13 Interoperability with the SASL GSSAPI mechanism The Kerberos V5 GSS API RFC1964 mechanism is currently used in SASL under the name GSSAPI see GSSAPI mechanism RFC4752 The Kerberos V5 mechanism may also be used with the GS2 family This causes an interoperability problem which is discussed and resolved below 13 1 The interoperability problem The SASL GSSAPI mechanism is not wire compatible with the Kerberos V GSS API mechanism used as a SASL GS2 mechanism Josefsson Williams Expires March 13 2010 Page 17 Internet Draft SASL GS2 September 2009 If a client or server only support Kerberos V5 under the GSSAPI name and the server or client only support Kerberos V5 under the

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


  • 1 1 The ASN 1 DER encoding of the OID including the tag and length is in hex 06 07 2b 06 01 05 05 01 01 The SHA 1 hash of the ASN 1 DER encoding is in hex 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad Convert the first 7 octets to binary drop the last bit and re group them in groups of 5 and convert them back to decimal which results in these computations hex 1c f8 f4 2b 5a 9f 80 binary 00011100 11111000 11110100 00101011 01011010 10011111 1000000 binary in groups of 5 00011 10011 11100 01111 01000 01010 11010 11010 10011 11110 00000 decimal of each group 3 19 28 15 8 10 26 26 19 30 0 base32 encoding D T 4 P I K 2 2 T 6 A The last step translate each decimal value using table 3 in Base32 RFC4648 Thus the SASL mechanism name for the SPKM 1 GSSAPI mechanism is GS2 DT4PIK22T6A The OID for the Kerberos V5 GSS API mechanism RFC1964 is 1 2 840 113554 1 2 2 and its DER encoding is in hex 06 09 2A 86 48 86 F7 12 01 02 02 The SHA 1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 93 25 51 6a fc ff 04 b0 43 60 Convert the 7 octets to binary drop the last bit and re group them in groups of 5 and convert them back to decimal which results in these computations Josefsson Williams Expires November 27 2009 Page 6 Internet Draft SASL GS2 May 2009 hex 82 d2 73 25 76 6b d6 binary 10000010 11010010 01110011 00100101 01110110 01101011 1101011 binary in groups of 5 10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011 decimal of each group 16 11 9 7 6 9 11 22 13 15 11 base32 encoding Q L J H G J L W N P L The last step translate each decimal value using table 3 in Base32 RFC4648 Thus the SASL mechanism name for the Kerberos V5 GSSAPI mechanism would be GS2 QLJHGJLWNPL and because this mechanism supports channel binding GS2 QLJHGJLWNPL PLUS Instead the next section assigns the Kerberos V5 mechanism a non hash derived mechanism name 3 4 Grandfathered mechanism names Some older GSS API mechanisms were not specified with a SASL GS2 mechanism name Using a shorter name can be useful nonetheless We specify the names GS2 KRB5 and GS2 KRB5 PLUS for the Kerberos V5 mechanism to be used as if the original specification documented it See Section 15 4 SASL Authentication Exchange Message Format 4 1 SASL Messages During the SASL authentication exchange for GS2 a number of messages following the following format is sent between the client and server This number is the same as the number of context tokens that the GSS API mechanism would normally require in order to establish a security context or to fail to do so Note that when using a GS2 mechanism the SASL client is always a GSS API initiator and the SASL server is always a GSS API acceptor Thus the SASL client calls GSS Init sec context and the server calls GSS Accept sec context Josefsson Williams Expires November 27 2009 Page 7 Internet Draft SASL GS2 May 2009 All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for the initial security context token The client and server MAY send GSS API error tokens tokens output by GSS Init sec context or GSS Accept sec context when the major status code is other than GSS S COMPLETE or GSS S CONTINUE NEEDED As this indicate an error condition after sending the token the sending side should fail the authentication The initial security context token is modified as follows o The RFC2743 section 3 1 initial context token header MUST be removed if present If the header is not present the client MUST send a gs2 nonstd flag flag see below On the server side this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context except when the gs2 nonstd flag is sent o A GS2 header MUST be prefixed to the resulting initial context token This header has the form gs2 header given below in ABNF RFC5234 UTF8 1 safe x01 2B x2D 3C x3E 7F As UTF8 1 in RFC 3629 except NUL and UTF8 2 UTF8 3 UTF8 4 UTF8 char safe UTF8 1 safe UTF8 2 UTF8 3 UTF8 4 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname GS2 has to transport an authzid since the GSS API has no equivalent gs2 nonstd flag F F means the mechanism is not a standard GSS API mechanism in that the RFC2743 section 3 1 header was missing gs2 cb flag p n y GS2 channel binding CB flag p client supports and used CB n client does not support CB y client supports CB thinks the server does not gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid The GS2 header is gs2 header When the gs2 nonstd flag flag is present the client did not find remove a RFC2743 section 3 1 token header from the initial token Josefsson Williams Expires November 27 2009 Page 8 Internet Draft SASL GS2 May 2009 returned by GSS Init sec context This signals to the server that it MUST NOT re add the data that is normally removed by the client The gs2 cb flag signals the channel binding mode One of p n or y is used A p means the client supports and used a channel binding A n means that the client does not support channel binding A y means the client supports channel binding but believes the server does not so it did not use a channel binding See the next section for more details The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 RFC3629 with three exceptions o The NUL characters is forbidden as required by section 3 4 1 of RFC4422 o The server MUST replace any comma in the string with 2C o The server MUST replace any equals in the string with 3D If a server sends a string that does not conform to this syntax the client MUST reject authentication 5 Channel Bindings If the server supports channel binding then it MUST list both forms of the SASL mechanism name for each GSS API mechanism supported via GS2 i e GSS API mechanisms that support channel binding If the client supports channel binding and the server does not i e the server did not advertise the PLUS names then the client MUST either fail authentication or it MUST set the channel binding flag in the GS2 initial security context token to y and MUST NOT include application channel binding data in the GSS API channel binding input to GSS Init sec context If the client supports channel binding and the server also does then the client MUST set the channel binding flag in the GS2 initial security context token to p and MUST include application channel binding data in the GSS API channel binding input to GSS Init sec context This is done by pre pending the gs2 header to the application s channel binding data If the application did not provide channel binding data then the GS2 header is used as though it were application provided channel binding data If the client does not support channel binding then it MUST set the channel binding flag in the GS2 initial security context token to n and MUST NOT include application channel binding data in the GSS API channel binding input to GSS Init sec context Josefsson Williams Expires November 27 2009 Page 9 Internet Draft SASL GS2 May 2009 Upon receipt of the initial authentication message the server checks the channel binding flag in the GS2 header and constructs a channel binding data input for GSS Accept sec context accordingly If the client channel binding flag was n then the server MUST NOT include application channel binding data in the GSS API channel binding input to GSS Accept sec context If the client channel binding flag was y and the server does support channel binding then the server MUST fail authentication If the client channel binding flag was p the server MUST include application channel binding data in the GSS API channel binding input to GSS Accept sec context For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 5 1 Channel Binding to TLS Channels If an external TLS channel is to be bound into the GS2 authentication and if the channel was established using a X 509 RFC5280 server certificate to authenticate the server then the GS2 client and server MUST use the tls server end point channel binding type See the IANA Channel Binding Types registry If an external TLS channel is to be bound into the GS2 authentication and if the channel was established either without the use of any X 509 server certificate to authenticate the server or with a non X 509 server certificate then the GS2 client and server MUST use the tls unique channel binding type 6 Examples Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given C Request authentication exchange S Empty Challenge C na someuser S Send reply context token as is C Empty message S Outcome of authentication exchange Josefsson Williams Expires November 27 2009 Page 10 Internet Draft SASL GS2 May 2009 Example 2 a one and one half round trip GSS API context token exchange C Request authentication exchange S Empty Challenge C na someuser S Send reply context token as is C Send reply context token as is S Outcome of authentication exchange Example 3 a two round trip GSS API context token exchange no standard token header C Request authentication exchange S Empty Challenge C Fna someuser S Send reply context token as is C Send reply context token as is S Send reply context token as is C Empty message S Outcome of authentication exchange Example 4 using channel binding C Request authentication exchange S Empty Challenge C pa someuser S Send reply context token as is GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See section 3 of RFC4422 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE Josefsson Williams Expires November 27 2009 Page 11 Internet Draft SASL GS2 May 2009 o If the client s GS2 channel binding flag was y and the server supports channel binding o If the client requires use of channel binding and the server did not advertise support for channel binding o Authorization of client principal i e src name in GSS Accept sec context to requested authzid failed o If the client is not authorized to the requested authzid or an authzid could not be derived from the client s initiator principal name 8 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the setting of req flags related to per message tokens is irrelevant 9 Naming There s no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor principal names see RFC2743 section 4 1 and clients will typically have username initiator principal names see RFC2743 section 4 2 10 GSS Inquire SASLname for mech call To allow SASL implementations to query for the SASL mechanism name of a GSS API mechanism we specify a new GSS API function for this purpose Josefsson Williams Expires November 27 2009 Page 12 Internet Draft SASL GS2 May 2009 Inputs o desired mech OBJECT IDENTIFIER Outputs o sasl mech name UTF 8 STRING SASL name for this mechanism o mech name UTF 8 STRING name of this mechanism possibly localized o mech description UTF 8 STRING possibly localized description of this mechanism Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that a desired mech was unsupported by the GSS API implementation The GSS Inquire SASLname for mech call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in a human readable form The output variable sasl mech name will hold the IANA registered mechanism name for the GSS API mechanism or if none is registered a mechanism named computed from the OID as described in section 3 1 of this document Josefsson Williams Expires November 27 2009 Page 13 Internet Draft SASL GS2 May 2009 10 1 gss inquire saslname for mech The C binding for the GSS Inquire SASLname for mech call is as follows OM uint32 gss inquire saslname for mech OM uint32 minor status const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description Purpose Output the SASL mechanism name of a GSS API mechanism It also returns a name and description of the mechanism in a human readable form Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 11 GSS Inquire mech for SASLname call To allow SASL clients to more efficiently identify which GSS API mechanism a particular SASL mechanism name refers to we specify a new GSS API utility function for this purpose Josefsson Williams Expires November 27 2009 Page 14 Internet Draft SASL GS2 May 2009 Inputs o sasl mech name UTF 8 STRING SASL name of mechanism Outputs o mech type OBJECT IDENTIFIER must be explicit mechanism and not default specifier Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that no supported GSS API mechanism had the indicated sasl mech name The GSS Inquire mech for SASLname call is used to get the GSS API mechanism OID associated with a SASL mechanism name Josefsson Williams Expires November 27 2009 Page 15 Internet Draft SASL GS2 May 2009 11 1 gss inquire mech for saslname The C binding for the GSS Inquire mech for SASLname call is as follows OM uint32 gss inquire mech for saslname OM uint32 minor status const gss buffer t sasl mech name gss OID mech type Purpose Output GSS API mechanism OID of mechanism associated with given sasl mech name Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 12 Security Layers GS2 does not currently support SASL security layers Applications that need integrity protection or confidentiality and integrity protection MUST use either channel binding to a secure external channel or a SASL mechanism that does provide security layers NOTE WELL the GS2 client s first authentication message MUST always start with F p n or y otherwise the server MUST fail authentication This will allow us to add support for security layers in the future if it were to become necessary Note that adding security layer support to GS2 must not break existing SASL GS2 applications which can be accomplished by making security layers optional A sketch of how to add sec layer support Add a way for the client to a make an offer of sec layers and max buffer b make an opportunistic selection of sec layer and buffer size both in the first client authentication message and starting with a character other than F n y or p The server could accept the Josefsson Williams Expires November 27 2009 Page 16 Internet Draft SASL GS2 May 2009 opportunistic proposal reply token prefixed with a byte indicating acceptance or reject it along with an indication of the server s acceptable sec layers and max buffer size In the latter case the GSS API security context token exchange must be abandoned and recommenced although this would be a detail of the GS2 bridge not exposed to the SASL application The negotiation would be protected via GSS channel binding as with the rest of GS2 13 Interoperability with the SASL GSSAPI mechanism The Kerberos V5 GSS API RFC1964 mechanism is currently used in SASL under the name GSSAPI see GSSAPI mechanism RFC4752 The Kerberos V5 mechanism may also be used with the GS2 family This causes an interoperability problem which is discussed and resolved below 13 1 The interoperability problem The SASL GSSAPI mechanism is not wire compatible with the Kerberos V GSS API mechanism used as a SASL GS2 mechanism 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 mechanism negotiation will fail 13 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 SASL GSSAPI mechanism lacks support for channel bindings which means that using an external secure channel may not be

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


  • Internet Draft SASL GS2 April 2009 name This name denotes that the server does not support channel binding Add the suffix PLUS and the resulting name denotes that the server does support channel binding 3 2 Computing mechanism names manually The hash derived GS2 SASL mechanism name may be computed manually This is useful when the set of supported GSS API mechanisms is known in advance It also obliterate the need to implement Base32 SHA 1 and DER in the SASL mechanism The computed mechanism name can be used directly in the implementation and the implementation need not concern itself with that the mechanism is part of a mechanism family 3 3 Examples The OID for the SPKM 1 mechanism RFC2025 is 1 3 6 1 5 5 1 1 The ASN 1 DER encoding of the OID including the tag and length is in hex 06 07 2b 06 01 05 05 01 01 The SHA 1 hash of the ASN 1 DER encoding is in hex 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad Convert the first 7 octets to binary drop the last bit and re group them in groups of 5 and convert them back to decimal which results in these computations hex 1c f8 f4 2b 5a 9f 80 binary 00011100 11111000 11110100 00101011 01011010 10011111 1000000 binary in groups of 5 00011 10011 11100 01111 01000 01010 11010 11010 10011 11110 00000 decimal of each group 3 19 28 15 8 10 26 26 19 30 0 base32 encoding D T 4 P I K 2 2 T 6 A The last step translate each decimal value using table 3 in Base32 RFC4648 Thus the SASL mechanism name for the SPKM 1 GSSAPI mechanism is GS2 DT4PIK22T6A The OID for the Kerberos V5 GSS API mechanism RFC1964 is 1 2 840 113554 1 2 2 and its DER encoding is in hex 06 09 2A 86 48 86 F7 12 01 02 02 The SHA 1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 93 25 51 6a fc ff 04 b0 43 60 Convert the 7 octets to binary drop Josefsson Williams Expires October 20 2009 Page 6 Internet Draft SASL GS2 April 2009 the last bit and re group them in groups of 5 and convert them back to decimal which results in these computations hex 82 d2 73 25 76 6b d6 binary 10000010 11010010 01110011 00100101 01110110 01101011 1101011 binary in groups of 5 10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011 decimal of each group 16 11 9 7 6 9 11 22 13 15 11 base32 encoding Q L J H G J L W N P L The last step translate each decimal value using table 3 in Base32 RFC4648 Thus the SASL mechanism name for the Kerberos V5 GSSAPI mechanism would be GS2 QLJHGJLWNPL and because this mechanism supports channel binding GS2 QLJHGJLWNPL PLUS Instead the next section assigns the Kerberos V5 mechanism a non hash derived mechanism name 3 4 Grandfathered mechanism names Some older GSS API mechanisms were not specified with a SASL GS2 mechanism name Using a shorter name can be useful nonetheless We specify the names GS2 KRB5 and GS2 KRB5 PLUS for the Kerberos V5 mechanism to be used as if the original specification documented it See Section 15 4 SASL Authentication Exchange Message Format 4 1 SASL Messages During the SASL authentication exchange for GS2 a number of messages following the following format is sent between the client and server This number is the same as the number of context tokens that the GSS API mechanism would normally require in order to establish a security context or to fail to do so Note that when using a GS2 mechanism the SASL client is always a GSS API initiator and the SASL server is always a GSS API acceptor Thus Josefsson Williams Expires October 20 2009 Page 7 Internet Draft SASL GS2 April 2009 the SASL client calls GSS Init sec context and the server calls GSS Accept sec context All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for the initial security context token Also the server SHOULD refrain from sending GSS API error tokens tokens output by GSS Init sec context or GSS Accept sec context along with a major status code other than GSS S COMPLETE or GSS S CONTINUE NEEDED as SASL applications handle error conditions The initial security context token is modified as follows o The RFC2743 section 3 1 initial context token header MUST be removed if present If the header is not present the client MUST send a gs2 nonstd flag flag see below On the server side this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context except when the gs2 nonstd flag is sent o A GS2 header MUST be prefixed to the resulting initial context token This header has the form gs2 header given below in ABNF RFC5234 UTF8 1 safe x01 2B x2D 3C x3E 7F As UTF8 1 in RFC 3629 except NUL and UTF8 2 UTF8 3 UTF8 4 UTF8 char safe UTF8 1 safe UTF8 2 UTF8 3 UTF8 4 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname GS2 has to transport an authzid since the GSS API has no equivalent gs2 nonstd flag F F means the mechanism is not a standard GSS API mechanism in that the RFC2743 section 3 1 header was missing gs2 cb flag p n y GS2 channel binding CB flag p client supports and used CB n client does not support CB y client supports CB thinks the server does not gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid The GS2 header is gs2 header Josefsson Williams Expires October 20 2009 Page 8 Internet Draft SASL GS2 April 2009 When the gs2 nonstd flag flag is present the client did not find remove a RFC2743 section 3 1 token header from the initial token returned by GSS Init sec context This signals to the server that it MUST NOT re add the data that is normally removed by the client The gs2 cb flag signals the channel binding mode One of p n or y is used A p means the client supports and used a channel binding A n means that the client does not support channel binding A y means the client supports channel binding but believes the server does not so it did not use a channel binding See the next section for more details The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 RFC3629 with three exceptions o The NUL characters is forbidden as required by section 3 4 1 of RFC4422 o The server MUST replace any comma in the string with 2C o The server MUST replace any equals in the string with 3D If a server sends a string that does not conform to this syntax the client MUST reject authentication 5 Channel Bindings If the server supports channel binding then it MUST list both forms of the SASL mechanism name for each GSS API mechanism supported via GS2 i e GSS API mechanisms that support channel binding If the client supports channel binding and the server does not i e the server did not advertise the PLUS names then the client MUST either fail authentication or it MUST set the channel binding flag in the GS2 initial security context token to y and MUST NOT include application channel binding data in the GSS API channel binding input to GSS Init sec context If the client supports channel binding and the server also does then the client MUST set the channel binding flag in the GS2 initial security context token to p and MUST include application channel binding data in the GSS API channel binding input to GSS Init sec context This is done by pre pending the gs2 header to the application s channel binding data If the application did not provide channel binding data then the GS2 header is used as though it were application provided channel binding data If the client does not support channel binding then it MUST set the channel binding flag in the GS2 initial security context token to n and MUST NOT include application channel binding data in the GSS API Josefsson Williams Expires October 20 2009 Page 9 Internet Draft SASL GS2 April 2009 channel binding input to GSS Init sec context Upon receipt of the initial authentication message the server checks the channel binding flag in the GS2 header and constructs a channel binding data input for GSS Accept sec context accordingly If the client channel binding flag was n then the server MUST NOT include application channel binding data in the GSS API channel binding input to GSS Accept sec context If the client channel binding flag was y and the server does support channel binding then the server MUST fail authentication If the client channel binding flag was p the server MUST include application channel binding data in the GSS API channel binding input to GSS Accept sec context For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 6 Examples Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given C Request authentication exchange S Empty Challenge C na someuser S Send reply context token as is C Empty message S Outcome of authentication exchange Example 2 a one and one half round trip GSS API context token exchange C Request authentication exchange S Empty Challenge C na someuser S Send reply context token as is C Send reply context token as is S Outcome of authentication exchange Josefsson Williams Expires October 20 2009 Page 10 Internet Draft SASL GS2 April 2009 Example 3 a two round trip GSS API context token exchange no standard token header C Request authentication exchange S Empty Challenge C Fna someuser S Send reply context token as is C Send reply context token as is S Send reply context token as is C Empty message S Outcome of authentication exchange Example 4 using channel binding C Request authentication exchange S Empty Challenge C pa someuser S Send reply context token as is GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See section 3 of RFC4422 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o If the client s GS2 channel binding flag was y and the server supports channel binding o If the client requires use of channel binding and the server did not advertise support for channel binding o Authorization of client principal i e src name in GSS Accept sec context to requested authzid failed o If the client is not authorized to the requested authzid or an authzid could not be derived from the client s initiator principal name Josefsson Williams Expires October 20 2009 Page 11 Internet Draft SASL GS2 April 2009 8 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the setting of req flags related to per message tokens is irrelevant 9 Naming There s no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor principal names see RFC2743 section 4 1 and clients will typically have username initiator principal names see RFC2743 section 4 2 10 GSS Inquire SASLname for mech call To allow SASL implementations to query for the SASL mechanism name of a GSS API mechanism we specify a new GSS API function for this purpose Inputs o desired mech OBJECT IDENTIFIER Outputs o sasl mech name UTF 8 STRING SASL name for this mechanism o mech name UTF 8 STRING name of this mechanism possibly localized o mech description UTF 8 STRING possibly localized description of this mechanism Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that a desired mech was unsupported by the GSS API implementation The GSS Inquire SASLname for mech call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in a human readable form Josefsson Williams Expires October 20 2009 Page 12 Internet Draft SASL GS2 April 2009 10 1 gss inquire saslname for mech The C binding for the GSS Inquire SASLname for mech call is as follows OM uint32 gss inquire saslname for mech OM uint32 minor status const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description Purpose Output the SASL mechanism name of a GSS API mechanism It also returns a name and description of the mechanism in a human readable form Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 11 GSS Inquire mech for SASLname call To allow SASL clients to more efficiently identify which GSS API mechanism a particular SASL mechanism name refers to we specify a new GSS API utility function for this purpose Josefsson Williams Expires October 20 2009 Page 13 Internet Draft SASL GS2 April 2009 Inputs o sasl mech name UTF 8 STRING SASL name of mechanism Outputs o mech type OBJECT IDENTIFIER must be explicit mechanism and not default specifier Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that no supported GSS API mechanism had the indicated sasl mech name The GSS Inquire mech for SASLname call is used to get the GSS API mechanism OID associated with a SASL mechanism name Josefsson Williams Expires October 20 2009 Page 14 Internet Draft SASL GS2 April 2009 11 1 gss inquire mech for saslname The C binding for the GSS Inquire mech for SASLname call is as follows OM uint32 gss inquire mech for saslname OM uint32 minor status const gss buffer t sasl mech name gss OID mech type Purpose Output GSS API mechanism OID of mechanism associated with given sasl mech name Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 12 Security Layers GS2 does not currently support SASL security layers Applications that need integrity protection or confidentiality and integrity protection MUST use either channel binding to a secure external channel or a SASL mechanism that does provide security layers NOTE WELL the GS2 client s first authentication message MUST always start with F p n or y otherwise the server MUST fail authentication This will allow us to add support for security layers in the future if it were to become necessary Note that adding security layer support to GS2 must not break existing SASL GS2 applications which can be accomplished by making security layers optional A sketch of how to add sec layer support Add a way for the client to a make an offer of sec layers and max buffer b make an opportunistic selection of sec layer and buffer size both in the first client authentication message and starting with a character other than F n y or p The server could accept the Josefsson Williams Expires October 20 2009 Page 15 Internet Draft SASL GS2 April 2009 opportunistic proposal reply token prefixed with a byte indicating acceptance or reject it along with an indication of the server s acceptable sec layers and max buffer size In the latter case the GSS API security context token exchange must be abandoned and recommenced although this would be a detail of the GS2 bridge not exposed to the SASL application The negotiation would be protected via GSS channel binding as with the rest of GS2 13 Interoperability with the SASL GSSAPI mechanism The Kerberos V5 GSS API RFC1964 mechanism is currently used in SASL under the name GSSAPI see GSSAPI mechanism RFC4752 The Kerberos V5 mechanism may also be used with the GS2 family This causes an interoperability problem which is discussed and resolved below 13 1 The interoperability problem The SASL GSSAPI mechanism is not wire compatible with the Kerberos V GSS API mechanism used as a SASL GS2 mechanism 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 mechanism negotiation will fail 13 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 SASL GSSAPI mechanism lacks support for channel bindings which means that using an external secure channel may not be sufficient protection against active attackers see RFC5056 mitm 13 3 Additional Recommendations If the application requires security layers then it MUST prefer the SASL GSSAPI mechanism over GS2 KRB5 or GS2 KRB5 PLUS If the application can use channel binding to an external channel then it is RECOMMENDED that it

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


  • is not a GS2 family mechanism name This name denotes that the server does not support channel binding Add the suffix PLUS and the resulting name denotes that the server does support channel binding 3 2 Computing mechanism names manually The hash derived GS2 SASL mechanism name may be computed manually This is useful when the set of supported GSS API mechanisms is known in advance It also obliterate the need to implement Base32 SHA 1 and DER in the SASL mechanism The computed mechanism name can be used directly in the implementation and the implementation need not concern itself with that the mechanism is part of a mechanism family Josefsson Williams Expires September 24 2009 Page 5 Internet Draft SASL GS2 March 2009 3 3 Examples The OID for the SPKM 1 mechanism RFC2025 is 1 3 6 1 5 5 1 1 The ASN 1 DER encoding of the OID including the tag and length is in hex 06 07 2b 06 01 05 05 01 01 The SHA 1 hash of the ASN 1 DER encoding is in hex 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad Convert the first 7 octets to binary drop the last bit and re group them in groups of 5 and convert them back to decimal which results in these computations hex 1c f8 f4 2b 5a 9f 80 binary 00011100 11111000 11110100 00101011 01011010 10011111 1000000 binary in groups of 5 00011 10011 11100 01111 01000 01010 11010 11010 10011 11110 00000 decimal of each group 3 19 28 15 8 10 26 26 19 30 0 base32 encoding D T 4 P I K 2 2 T 6 A The last step translate each decimal value using table 3 in Base32 RFC4648 Thus the SASL mechanism name for the SPKM 1 GSSAPI mechanism is GS2 DT4PIK22T6A The OID for the Kerberos V5 GSS API mechanism RFC1964 is 1 2 840 113554 1 2 2 and its DER encoding is in hex 06 09 2A 86 48 86 F7 12 01 02 02 The SHA 1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 93 25 51 6a fc ff 04 b0 43 60 Convert the first ten octets to binary and re group them in groups of 5 and convert them back to decimal which results in these computations Josefsson Williams Expires September 24 2009 Page 6 Internet Draft SASL GS2 March 2009 hex 82 d2 73 25 76 6b d6 binary 10000010 11010010 01110011 00100101 01110110 01101011 1101011 binary in groups of 5 10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011 decimal of each group 16 11 9 7 6 9 11 22 13 15 11 base32 encoding Q L J H G J L W N P L The last step translate each decimal value using table 3 in Base32 RFC4648 Thus the SASL mechanism name for the Kerberos V5 GSSAPI mechanism would be GS2 QLJHGJLWNPL and because this mechanism supports channel binding GS2 QLJHGJLWNPL PLUS But instead we assign the Kerberos V mechanism a non hash derived mechanism name KerberosV GS2 and KerberosV GS2 PLUS see Section 15 4 SASL Authentication Exchange Message Format 4 1 SASL Messages During the SASL authentication exchange for GS2 a number of messages following the following format is sent between the client and server This number is the same as the number of context tokens that the GSS API mechanism would normally require in order to establish a security context or to fail to do so Note that when using a GS2 mechanism the SASL client is always a GSS API initiator and the SASL server is always a GSS API acceptor Thus the SASL client calls GSS Init sec context and the server calls GSS Accept sec context All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for the initial security context token Also the server SHOULD refrain from sending GSS API error tokens tokens output by GSS Init sec context or GSS Accept sec context along with a major status code other than GSS S COMPLETE or GSS S CONTINUE NEEDED as SASL applications handle error conditions Josefsson Williams Expires September 24 2009 Page 7 Internet Draft SASL GS2 March 2009 The initial security context token is modified as follows o The RFC2743 section 3 1 initial context token header MUST be removed if present and its presence is noted see below On the server side this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context o A GS2 header MUST be prefixed to the resulting initial context token This header has the form given below in ABNF RFC5234 UTF8 1 safe x01 2B x2D 3C x3E 7F As UTF8 1 in RFC 3629 except NUL and UTF8 2 UTF8 3 UTF8 4 UTF8 char safe UTF8 1 UTF8 2 UTF8 3 UTF8 4 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname GS2 has to transport an authzid since the GSS API has no equivalent gs2 std mech F F means the mechanism is NOT is a standard GSS API mechanism in that the RFC2743 section 3 1 header was missing gs2 cb flag n y p GS2 channel binding CB flag n client does not support CB y client supports CB thinks the server does not p client supports and used CB gs2 header gs2 std mech gs2 cb flag gs2 authzid The GS2 header is gs2 header gs2 std mech is present if the GSS API mechanism s initial context token did not have the standard header defined in RFC2743 section 3 1 The GS2 header is also prepended to the application s channel binding data If the application did not provide channel binding data then the GS2 header is used as though it were application provided channel binding data The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 RFC3629 with three exceptions o The NUL characters is forbidden as required by section 3 4 1 of RFC4422 Josefsson Williams Expires September 24 2009 Page 8 Internet Draft SASL GS2 March 2009 o The server MUST replace any occurance of comma in the string with 2C o The server MUST replace any occurance of comma in the string with 3D If a server sends a string that does not conform to this syntax the client MUST reject authentication 5 Channel Bindings If the server supports channel binding then it must list both forms of the SASL mechanism name for each GSS API mechanism supported via GS2 i e GSS API mechanisms that support channel binding If the client supports channel binding and the server does not i e the server did not advertise the PLUS names then the client MUST either fail authentication or it MUST set the channel binding flag in the GS2 initial security context token to y and MUST NOT include application channel binding data in the GSS API channel binding input to GSS Init sec context If the client supports channel binding and the server also does then the client MUST set the channel binding flag in the GS2 initial security context token to p and MUST include application channel binding data in the GSS API channel binding input to GSS Init sec context If the client does not support channel binding then it MUST set the channel binding flag in the GS2 initial security context token to n and MUST NOT include application channel binding data in the GSS API channel binding input to GSS Init sec context Upon receipt of the initial authentication message the server checks the channel binding flag in the GS2 header and constructs a channel binding data input for GSS Accept sec context accordingly If the client channel binding flag was n then the server MUST NOT include application channel binding data in the GSS API channel binding input to GSS Accept sec context If the client channel binding flag was y and the server does support channel binding then the server MUST fail authentication If the client channel binding flag was p the server MUST include application channel binding data in the GSS API channel binding input to GSS Accept sec context For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 Josefsson Williams Expires September 24 2009 Page 9 Internet Draft SASL GS2 March 2009 6 Examples Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given C Request authentication exchange S Empty Challenge C nauthzid someuser S Send reply context token as is C Empty message S Outcome of authentication exchange Example 2 a one and one half round trip GSS API context token exchange C Request authentication exchange S Empty Challenge C nauthzid someuser S Send reply context token as is C Send reply context token as is S Outcome of authentication exchange Example 3 a two round trip GSS API context token exchange C Request authentication exchange S Empty Challenge C nauthzid someuser S Send reply context token as is C Send reply context token as is S Send reply context token as is C Empty message S Outcome of authentication exchange Example 4 using channel binding C Request authentication exchange S Empty Challenge C yauthzid someuser S Send reply context token as is GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty Josefsson Williams Expires September 24 2009 Page 10 Internet Draft SASL GS2 March 2009 challenge zero byte string if it has not yet received a token from the client See section 3 of RFC4422 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o If the client s GS2 channel binding flag was y and the server supports channel binding o If the client requires use of channel binding and the server did not advertise support for channel binding o Authorization of client principal i e src name in GSS Accept sec context to requested authzid failed o If the client is not authorized to the requested authzid or an authzid could not be derived from the client s initiator principal name 8 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the setting of req flags related to per message tokens is irrelevant 9 Naming There s no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor principal names see RFC2743 section 4 1 and clients will typically have username initiator principal names see RFC2743 section 4 2 10 GSS Mechanism SASLname call To allow SASL implementations to query for the SASL mechanism name of a GSS API mechanism we specify a new GSS API function for this purpose Josefsson Williams Expires September 24 2009 Page 11 Internet Draft SASL GS2 March 2009 Inputs o desired mech OBJECT IDENTIFIER Outputs o sasl mech name OCTET STRING SASL name for this mechanism really ASCII o mech name UTF 8 STRING name of this mechanism possibly localized o mech description UTF 8 STRING possibly localized description of this mechanism Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that a disred mech was unsupported by the GSS API implementation The GSS Mechanism SASLname call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in a human readable form Josefsson Williams Expires September 24 2009 Page 12 Internet Draft SASL GS2 March 2009 10 1 gss mechanism saslname The C binding for the GSS Mechanism SASLname call is as follows OM uint32 gss mechanism saslname OM uint32 minor status const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description Purpose Output the SASL mechanism name of a GSS API mechanism Also output a name and description of the mechanism in a human readable form Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 11 GSS Inquire mech for SASLname call To allow SASL clients to more efficiently identify which GSS API mechanism a particular SASL mechanism name refers to we specify a new GSS API utility function for this purpose Josefsson Williams Expires September 24 2009 Page 13 Internet Draft SASL GS2 March 2009 Inputs o sasl mech name OCTET STRING SASL name of mechanism really ASCII Outputs o mech type OBJECT IDENTIFIER must be explicit mechanism and not default specifier Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that no supported GSS API mechanism had the indicated sasl mech name The GSS Inquire mech for SASLname call is used to get the GSS API mechanism OID associated with a SASL mechanism name Josefsson Williams Expires September 24 2009 Page 14 Internet Draft SASL GS2 March 2009 11 1 gss inquire mech for saslname The C binding for the GSS Inquire mech for SASLname call is as follows OM uint32 gss inquire mech for saslname OM uint32 minor status const gss buffer t sasl mech name gss OID mech type Purpose Output GSS API mechanism OID of mechanism associated with given sasl mech name Parameters minor status Integer modify Mechanism specific status code Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported 12 Security Layers GS2 does not currently support SASL security layers Applications that need integrity protection or confidentiality and integrity protection MUST use either channel binding to a secure external channel or a SASL mechanism that does provide security layers NOTE WELL the GS2 client s first authentication message MUST always start with F n y or p otherwise the server MUST fail authentication This will allow us to add support for security layers in the future if it were to become necessary Note that adding security layer support to GS2 must not break existing SASL GS2 applications which can be accomplished by making security layers optional A sketch of how to add sec layer support Add a way for the client to a make an offer of sec layers and max buffer b make an opportunistic selection of sec layer and buffer size both in the first client authentication message and starting with a character other than F n y or p The server could accept the Josefsson Williams Expires September 24 2009 Page 15 Internet Draft SASL GS2 March 2009 opportunistic proposal reply token prefixed with a byte indicating acceptance or reject it along with an indication of the server s acceptable sec layers and max buffer size In the latter case the GSS API security context token exchange must be abandoned and recommenced although this would be a detail of the GS2 bridge not exposed to the SASL application The negotiation would be protected via GSS channel binding as with the rest of GS2 13 Interoperability with the SASL GSSAPI mechanism The Kerberos V5 GSS API RFC1964 mechanism is currently used in SASL under the name GSSAPI see GSSAPI mechanism RFC4752 The Kerberos V5 mechanism may also be used with the GS2 family This causes an interopability problem which is discussed and resolved below 13 1 The interoperability problem The SASL GSSAPI mechanism is not wire compatible with the Kerberos V GSS API mechanism used as a SASL GS2 mechanism 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 mechanism negotiation will fail 13 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 SASL GSSAPI mechanism lacks support for channel bindings which means that using an external secure channel may not be sufficient protection against active attackers see RFC5056 mitm 13 3 Additional Recommendations If the application requires security layers then it MUST prefer the SASL GSSAPI mechanism over KerberosV GS2 If the application can use channel binding to an external channel then it is RECOMMENDED that it select Kerberos V5 through the GS2 mechanism rather than the GSSAPI mechanism Josefsson Williams Expires September 24 2009 Page 16 Internet Draft SASL GS2 March 2009 14 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 14 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 14 2 Security problem If a client s policy is to first prefer GSSAPI mechanism X then non GSSAPI mechanism Y then GSSAPI mechanism Z and if a server supports mechanisms Y and Z but not X then if the client attempts to negotiate mechanism X by using a GSS API mechanism

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


  • 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 Josefsson Expires January 14 2009 Page 10 Internet Draft SASL GS2 July 2008 processed first Upon successful establishment of the security context i e GSS Accept sec context returns GSS S COMPLETE the server SHOULD verify that the negotiated GSS API mechanism is indeed the registered one This is done by examining the value of the mech type parameter returned from the GSS Accept sec context call If the value differ the SASL authentication MUST be aborted Upon successful establishment of the security context and if the server used GSS C NO NAME GSS C NO CREDENTIAL to create acceptor credential handle the server SHOULD also check using the GSS Inquire context that the target name used by the client matches the GSS C NT HOSTBASED SERVICE service hostname name syntax where service is the service name specified in the application protocol s profile and hostname is the fully qualified host name of the server When GSS Accept sec context returns GSS S COMPLETE the server 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 Josefsson Expires January 14 2009 Page 11 Internet Draft SASL GS2 July 2008 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 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 Josefsson Expires January 14 2009 Page 12 Internet Draft SASL GS2 July 2008 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 RFC3629 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 Josefsson Expires January 14 2009 Page 13 Internet Draft SASL GS2 July 2008 4 3 4 Server first GS2 Wrap input The input to GS2 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 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 January 14 2009 Page 14 Internet Draft SASL GS2 July 2008 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 In order to accomodate the requirement in RFC5056 Authentication frameworks and mechanisms that support channel binding MUST communicate channel binding failure to applications implementations assert a bit in the security layer bitmask see Section 9 on negotiation failures 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 RFC5056 For easy reference the channel binding format used for The Transport Layer Security TLS Protocol RFC4346 is specified in I D altman tls channel bindings Josefsson Expires January 14 2009 Page 15 Internet Draft SASL GS2 July 2008 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 Empty Challenge 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 GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See section 3 of RFC4422 The next example illustrate when the client sends its Wrap token first Josefsson Expires January 14 2009 Page 16 Internet Draft SASL GS2 July 2008 C Request authentication exchange S Empty Challenge 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 January 14 2009 Page 17 Internet Draft SASL GS2 July 2008 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 January 14 2009 Page 18 Internet Draft SASL GS2 July 2008 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 January 14 2009 Page 19 Internet Draft SASL GS2 July 2008 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received e g length field checks discussed in section 4 1 fail 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 or channel binding negotiation failed o server side Authorization of client principal i e src name in GSS Acecpt sec context to requested authzid failed Josefsson Expires January 14 2009 Page 20 Internet Draft SASL GS2 July 2008 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 January 14 2009 Page 21 Internet Draft SASL GS2 July 2008 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 Whether the channel binding negotiation is successful or not may influence the security layer selection

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


  • 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 Josefsson Expires April 11 2008 Page 10 Internet Draft SASL GS2 October 2007 processed first Upon successful establishment of the security context i e GSS Accept sec context returns GSS S COMPLETE the server SHOULD verify that the negotiated GSS API mechanism is indeed the registered one This is done by examining the value of the mech type parameter returned from the GSS Accept sec context call If the value differ the SASL authentication MUST be aborted Upon successful establishment of the security context and if the server used GSS C NO NAME GSS C NO CREDENTIAL to create acceptor credential handle the server SHOULD also check using the GSS Inquire context that the target name used by the client matches the GSS C NT HOSTBASED SERVICE service hostname name syntax where service is the service name specified in the application protocol s profile and hostname is the fully qualified host name of the server When GSS Accept sec context returns GSS S COMPLETE the server 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 Josefsson Expires April 11 2008 Page 11 Internet Draft SASL GS2 October 2007 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 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 Josefsson Expires April 11 2008 Page 12 Internet Draft SASL GS2 October 2007 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 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 Josefsson Expires April 11 2008 Page 13 Internet Draft SASL GS2 October 2007 4 3 4 Server first GS2 Wrap input The input to GS2 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 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 April 11 2008 Page 14 Internet Draft SASL GS2 October 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 In order to accomodate the requirement in 16 Authentication frameworks and mechanisms that support channel binding MUST communicate channel binding failure to applications implementations MUST provide a way to communicate channel binding failures to applications 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 April 11 2008 Page 15 Internet Draft SASL GS2 October 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 Empty Challenge 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 GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See section 3 of 2 The next example illustrate when the client sends its Wrap token first Josefsson Expires April 11 2008 Page 16 Internet Draft SASL GS2 October 2007 C Request authentication exchange S Empty Challenge 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 April 11 2008 Page 17 Internet Draft SASL GS2 October 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 April 11 2008 Page 18 Internet Draft SASL GS2 October 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 April 11 2008 Page 19 Internet Draft SASL GS2 October 2007 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received e g length field checks discussed in section 4 1 fail 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 April 11 2008 Page 20 Internet Draft SASL GS2 October 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 April 11 2008 Page 21 Internet Draft SASL GS2 October 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

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



  •