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".
  • Diff: draft-ietf-sasl-gs2-14.txt - draft-ietf-sasl-gs2-15.txt
    integrity protection for the negotiation of channel binding either fail authentication or it MUST chose the non PLUS mechanism name and use a y gs2 cb flag If the client supports channel binding and the server appears to support it i e the client see a PLUS name then the client MUST use a p gs2 cb flag to indicate the channel binding type it is using The client generate the chan bindings input parameter for 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 GSS Init sec context as described below o Upon receipt of the initial authentication message the server Upon receipt of the initial authentication message the server checks checks the gs2 cb flag in the GS2 header and constructs a the gs2 cb flag in the GS2 header and constructs a chan bindings chan bindings parameter for GSS Accept sec context as described parameter for GSS Accept sec context as described below If the below If the client channel binding flag was y and the server client channel binding flag was y and the server did advertise did advertise support for channel bindings then the server MUST support for channel bindings then the server MUST fail fail authentication If the client channel binding flag was p authentication If the client channel binding flag was p and the and the server does not support the indicated channel binding type server does not support the indicated channel binding type then the then the server MUST fail authentication server MUST fail authentication For more discussions of channel bindings and the syntax of the For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 channel binding data for various security protocols see RFC5056 5 1 Content of GSS CHANNEL BINDINGS structure 5 1 Content of GSS CHANNEL BINDINGS structure The calls to GSS Init sec context and GSS Accept sec context takes a The calls to GSS Init sec context and GSS Accept sec context takes a chan bindings parameter The value is a GSS CHANNEL BINDINGS chan bindings parameter The value is a GSS CHANNEL BINDINGS structure RFC5554 structure RFC5554 The initiator address type and acceptor address type fields of the The initiator address type and acceptor address type fields of the GSS CHANNEL BINDINGS structure MUST be set to 0 The initiator GSS CHANNEL BINDINGS structure MUST be set to 0 The initiator address and acceptor address fields MUST be the empty string address and acceptor address fields MUST be the empty string The application data field MUST be set to the gs2 header concatenated 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 with when a gs2 cb flag of p is used the application s channel binding data if any binding data 5 2 Default Channel Binding 5 2 Default Channel Binding A default channel binding type agreement process for all SASL A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding application protocols that do not provide their own channel binding type agreement is provided as follows type agreement is provided as follows Clients and servers MUST implement the tls unique tls unique Clients and servers MUST implement the tls unique tls unique channel binding type Clients and servers SHOULD choose the highest I D altman tls channel bindings channel binding type Clients and layer innermost end to end TLS channel as the channel to bind to servers SHOULD choose the highest layer innermost end to end TLS channel as the channel to bind to Clients SHOULD choose the tls unique channel binding type Clients SHOULD choose the tls unique channel binding type Conversely clients MAY choose a different channel binding type based Conversely clients MAY choose a different channel binding type based on user input configuration or a future as yet undefined channel on user input configuration or a future as yet undefined channel binding type negotiation protocol Servers MUST choose the channel binding type negotiation protocol Servers MUST choose the channel binding type indicated by the client if they support it binding type indicated by the client if they support it 6 Examples 6 Examples Example 1 a one round trip GSS API context token exchange no Example 1 a one round trip GSS API context token exchange no skipping

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


  • Diff: draft-ietf-sasl-gs2-13.txt - draft-ietf-sasl-gs2-14.txt
    ad Convert the first 7 octets to binary drop the last 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 bit and re group them in groups of 5 and convert them back to skipping to change at page 7 line 37 skipping to change at page 7 line 37 mechanism name mechanism name 3 4 Grandfathered mechanism names 3 4 Grandfathered mechanism names Some older GSS API mechanisms were not specified with a SASL GS2 Some older GSS API mechanisms were not specified with a SASL GS2 mechanism name Using a shorter name can be useful nonetheless We mechanism name Using a shorter name can be useful nonetheless We specify the names GS2 KRB5 and GS2 KRB5 PLUS for the Kerberos V5 specify the names GS2 KRB5 and GS2 KRB5 PLUS for the Kerberos V5 mechanism to be used as if the original specification documented it mechanism to be used as if the original specification documented it See Section 15 See Section 15 4 SASL Authentication Exchange Message Forma t 3 5 Which mechanism names to advertise and selec t 4 1 SASL Messages Servers SHOULD advertise both non PLUS and the PLUS variant of a 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 If the client negotiates mechanisms then clients MUST select the PLUS variant if offered by the server Otherwise if the client does not negotiate mechanisms then it MUST use the non PLUS variant 4 SASL Authentication Exchange Message Format During the SASL authentication exchange for GS2 a number of messages During the SASL authentication exchange for GS2 a number of messages following the following format is sent between the client and server 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 On success this number is the same as the number of context tokens API mechanism would normally require in order to establish a security that the GSS API mechanism would normally require in order to context or to fail to do so establish a security context On failures the exchange can be terminated early by any party Note that when using a GS2 mechanism the SASL client is always a GSS When using a GS2 mechanism the SASL client is always a GSS API API initiator and the SASL server is always a GSS API acceptor Thus initiator and the SASL server is always a GSS API acceptor The the SASL client calls GSS Init sec context and the server calls client calls GSS Init sec context and the server calls GSS Accept sec context GSS Accept sec context All the SASL authentication messages exchanged are exactly the same All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for as the security context tokens of the GSS API mechanism except for the initial security context token the initial security context token The client and server MAY send GSS API error tokens tokens output by 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 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 status code is other than GSS S COMPLETE or GSS S CONTINUE NEEDED As this indicate an error condition after sending the token the As this indicate an error condition after sending the token the skipping to change at page 8 line 42 skipping to change at page 9 line 21 UTF8 char safe UTF8 1 safe 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 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname gs2 authzid a saslname GS2 has to transport an authzid since GS2 has to transport an authzid since the GSS API has no equivalent the GSS API has no equivalent gs2 nonstd flag F gs2 nonstd flag F F means the mechanism is not a F means the mechanism is not a standard GSS API mechanism in that the standard GSS API mechanism in that the RFC2743 section 3 1 header was missing RFC2743 section 3 1 header was missing gs2 cb flag p n y cb name 1 ALPHA DIGIT See RFC 5056 section 7 gs2 cb flag p cb name n y GS2 channel binding CB flag GS2 channel binding CB flag p client supports and used CB p client supports and used CB n client does not support CB n client does not support CB y client supports CB thinks the server y client supports CB thinks the server does not does not gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid The GS2 header is gs2 header The GS2 header is gs2 header When the gs2 nonstd flag flag is present the client did not find 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 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 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 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 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 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 and the name of the channel binding type is indicated A binding A y means the client supports channel binding but n means that the client does not support channel binding A y believes the server does not so it did not use a channel binding means the client supports channel binding but believes the server See the next section for more details 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 The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 RFC3629 with three exceptions encoded using UTF 8 RFC3629 with three exceptions o The NUL characters is forbidden as required by section 3 4 1 of o The NUL characters is forbidden as required by section 3 4 1 of RFC4422 RFC4422 o The server MUST replace any comma in the string with 2C o The server MUST replace any comma in the string with 2C o The server MUST replace any equals in the string with 3D 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 5 Channel Bindings If the server supports channel binding then it MUST list both forms If the client does not support channel binding then it MUST use a n of the SASL mechanism name for each GSS API mechanism supported via gs2 cb flag GS2 i e GSS API mechanisms that support channel binding If the client supports channel binding and the server does not i e If the client supports channel binding and the server does not appear the server did not advertise the PLUS names then the client MUST to i e the client did not see a PLUS name then the client MUST either fail authentication or it MUST set the channel binding flag in either fail authentication or it MUST chose the non PLUS mechanism the GS2 initial security context token to y and MUST NOT include name and use a y gs2 cb flag 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 If the client supports channel binding and the server appears to the client MUST set the channel binding flag in the GS2 initial support it i e the client see a PLUS name then the client MUST security context token to p and MUST include application channel use a p gs2 cb flag to indicate the channel binding type it is binding data in the GSS API channel binding input to using 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 The client generate the chan bindings input parameter for channel binding flag in the GS2 initial security context token to n GSS Init sec context as described below 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 Upon receipt of the initial authentication message the server checks the channel binding flag in the GS2 header and constructs a channel the gs2 cb flag in the GS2 header and constructs a chan bindings binding data input for GSS Accept sec context accordingly If the parameter for GSS Accept sec context as described below If the client channel binding flag was n then the server MUST NOT include client channel binding flag was y and the server did advertise application channel binding data in the GSS API channel binding input support for channel bindings then the server MUST fail to GSS Accept sec context If the client channel binding flag was authentication If the client channel binding flag was p and the y and the server does support channel binding then the server MUST server does not support the indicated channel binding type then the fail authentication If the client channel binding flag was p the server MUST fail authentication 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 For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 channel binding data for various security protocols see RFC5056 5 1 C hannel Binding to TLS Channels 5 1 C ontent of GSS CHANNEL BINDINGS structure If an external TLS channel is to be bound into the GS2 The calls to GSS Init sec context and GSS Accept sec context takes a authentication and if the channel was established using a X 509 chan bindings parameter The value is a GSS CHANNEL BINDINGS RFC5280 server certificate to authenticate the server then the GS2 structure RFC5554 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 The initiator address type and acceptor address type fields of the authentication and if the channel was established either without the GSS CHANNEL BINDINGS structure MUST be set to 0 The initiator use of any X 509 server certificate to authenticate the server or address and acceptor address fields MUST be the empty string with a non X 509 server certificate then the GS2 client and server MUST use the tls unique channel binding type 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 if any 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 Clients and servers MUST implement the tls unique tls unique channel binding type Clients and servers SHOULD choose the highest layer innermost end to end TLS channel as the channel to bind to Clients SHOULD choose the tls unique channel binding type Conversely clients MAY choose a different channel binding type based on user input configuration or a future as yet undefined channel binding type negotiation protocol Servers MUST choose the channel binding type indicated by the client if they support it 6 Examples 6 Examples Example 1 a one round trip GSS API context token exchange no Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given channel binding optional authzid given C Request authentication exchange C Request authentication exchange S Empty Challenge S Empty Challenge C na someuser initial context token with standard C n a someuser initial context token with standard header removed header removed S Send reply context token as is S Send reply context token as is C Empty message C Empty message S Outcome of authentication exchange S Outcome of authentication exchange Example 2 a one and one half round trip GSS API context token Example 2 a one and one half round trip GSS API context token exchange exchange no channel binding C Request authentication exchange C Request authentication exchange S Empty Challenge S Empty Challenge C n a someuser initial context token with standard C n initial context token with standard header removed header removed S Send reply context token as is S Send reply context token as is C Send reply context token as is C Send reply context token as is S Outcome of authentication exchange S Outcome of authentication exchange Example 3 a two round trip GSS API context token exchange no Example 3 a two round trip GSS API context token exchange no standard token header channel binding no standard token header C Request authentication exchange C Request authentication exchange S Empty Challenge S Empty Challenge C F na someuser initial context token without C F n initial context token without standard header standard header S Send reply context token as is S Send reply context token as is C Send reply context token as is C Send reply context token as is S Send reply context token as is S Send reply context token as is C Empty message C Empty message S Outcome of authentication exchange S Outcome of authentication exchange Example 4 using channel binding Example 4 using channel binding optional authzid given C Request authentication exchange C Request authentication exchange S Empty Challenge S Empty Challenge C pa someuser initial context token with standard C p tls unique a someuser initial context token with standard header removed S Send reply context token as is Example 5 using channel binding C Request authentication exchange S Empty Challenge C p tls unique initial context token with standard header removed 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 initial context token with standard header removed header removed S Send reply context token as is 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 initial context token with standard header removed S Send reply context token as is GSS API authentication is always initiated by the client The SASL GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from challenge zero byte string if it has not yet received a token from the client See section 3 of RFC4422 the client See section 3 of RFC4422 7 Authentication Conditions 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following Authentication MUST NOT succeed if any one of the following conditions are true conditions are true o GSS Init Accept sec context return anything other than o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE GSS S CONTINUE NEEDED or GSS S COMPLETE o 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 o If the client s GS2 channel binding flag was y and the server supports channel binding 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 o If the client requires use of channel binding and the server did not advertise support for channel binding not advertise support for channel binding o Authorization of client principal i e src name in o Authorization of client principal i e src name in

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

  • Diff: draft-ietf-sasl-gs2-12.txt - draft-ietf-sasl-gs2-13.txt
    GS2 If the GSS Inquire SASLname for mech interface is not used the GS2 implementation need some other mechanism to map mechanism OIDs to implementation need some other mechanism to map mechanism OIDs to SASL name internally In this case the implementation can only SASL name internally In this case the implementation can only support the mechanisms for which it knows the SASL name If the support the mechanisms for which it knows the SASL name If the GSS Inquire SASLname for mech call fails and the GS2 implementation GSS Inquire SASLname for mech call fails and the GS2 implementation cannot map the OID to a SASL mechanism name using some other means cannot map the OID to a SASL mechanism name using some other means it cannot use the particular GSS API mechanism since it does not know it cannot use the particular GSS API mechanism since it does not know its SASL mechanism name its SASL mechanism name If the GSS Inquire SASLname for mech call is successful but provides a zero length string FIXME is this a good idea simon it means the GSS API mechanism did not have a registered mechanism name In this case the GS2 implementation can derive the SASL mechanism name from the GSS API mechanism OID as follows 3 1 Generating SASL mechanism names from GSS API OIDs 3 1 Generating SASL mechanism names from GSS API OIDs For GSS API mechanisms whose SASL names are not defined together with For GSS API mechanisms whose SASL names are not defined together with the GSS API mechanism or in this document the SASL mechanism name is the GSS API mechanism or in this document the SASL mechanism name is concatenation of the string GS2 and the Base32 encoding RFC4648 concatenation of the string GS2 and the Base32 encoding RFC4648 with an upper case alphabet of the first 55 bits of the binary with an upper case alphabet of the first 55 bits of the binary SHA 1 hash FIPS 180 1 1995 string computed over the ASN 1 DER SHA 1 hash FIPS 180 1 1995 string computed over the ASN 1 DER encoding CCITT X690 2002 including the tag and length octets of encoding CCITT X690 2002 including the tag and length octets of the GSS API mechanism s Object Identifier The Base32 rules on the GSS API mechanism s Object Identifier The Base32 rules on padding characters and characters outside of the base32 alphabet are padding characters and characters outside of the base32 alphabet are skipping to change at page 8 line 11 skipping to change at page 8 line 9 Note that when using a GS2 mechanism the SASL client is always a GSS 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 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 the SASL client calls GSS Init sec context and the server calls GSS Accept sec context GSS Accept sec context All the SASL authentication messages exchanged are exactly the same All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for as the security context tokens of the GSS API mechanism except for the initial security context token the initial security context token Also the server SHOULD refrain from sending GSS API error tokens The client and server MAY send GSS API error tokens tokens output by tokens output by GSS Init sec context or GSS Accept sec context GSS Init sec context or GSS Accept sec context when the major along with a major status code other than GSS S COMPLETE or status code is other than GSS S COMPLETE or GSS S CONTINUE NEEDED GSS S CONTINUE NEEDED as SASL applications handle error conditions 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 The initial security context token is modified as follows o The RFC2743 section 3 1 initial context token header MUST be o The RFC2743 section 3 1 initial context token header MUST be removed if present If the header is not present the client MUST removed if present If the header is not present the client MUST send a gs2 nonstd flag flag see below On the server side send a gs2 nonstd flag flag see below On the server side this header MUST be recomputed and restored prior to passing the this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context except when the gs2 nonstd flag token to GSS Accept sec context except when the gs2 nonstd flag is sent is sent o A GS2 header MUST be prefixed to the resulting initial context o A GS2 header MUST be prefixed to the resulting initial context token This header has the form gs2 header given below in ABNF token This header has the form gs2 header given below in ABNF skipping to change at page 10 line 20 skipping to change at page 10 line 19 application channel binding data in the GSS API channel binding input application channel binding data in the GSS API channel binding input to GSS Accept sec context If the client channel binding flag was to GSS Accept sec context If the client channel binding flag was y and the server does support channel binding then the server MUST y and the server does support channel binding then the server MUST fail authentication If the client channel binding flag was p the fail authentication If the client channel binding flag was p the server MUST include application channel binding data in the GSS API server MUST include application channel binding data in the GSS API channel binding

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

  • Diff: draft-ietf-sasl-gs2-11.txt - draft-ietf-sasl-gs2-12.txt
    SASL Messages 4 1 SASL Messages During the SASL authentication exchange for GS2 a number of messages During the SASL authentication exchange for GS2 a number of messages following the following format is sent between the client and server 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 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 API mechanism would normally require in order to establish a security context or to fail to do so context or to fail to do so Note that when using a GS2 mechanism the SASL client is always a GSS 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 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 the SASL client calls GSS Init sec context and the server calls GSS Accept sec context GSS Accept sec context All the SASL authentication messages exchanged are exactly the same All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for as the security context tokens of the GSS API mechanism except for the initial security context token the initial security context token Also the server SHOULD refrain from sending GSS API error tokens Also the server SHOULD refrain from sending GSS API error tokens tokens output by GSS Init sec context or GSS Accept sec context tokens output by GSS Init sec context or GSS Accept sec context along with a major status code other than GSS S COMPLETE or along with a major status code other than GSS S COMPLETE or GSS S CONTINUE NEEDED as SASL applications handle error conditions GSS S CONTINUE NEEDED as SASL applications handle error conditions The initial security context token is modified as follows The initial security context token is modified as follows o The RFC2743 section 3 1 initial context token header MUST be o The RFC2743 section 3 1 initial context token header MUST be removed if present and its presence is noted see below On the removed if present If the header is not present the client MUST server side this header MUST be recomputed and restored prior to send a gs2 nonstd flag flag see below On the server side passing the token to GSS Accept sec context 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 o A GS2 header MUST be prefixed to the resulting initial context token This header has the form given below in ABNF RFC5234 token This header has the form gs2 header given below in ABNF RFC5234 UTF8 1 safe x01 2B x2D 3C x3E 7F UTF8 1 safe x01 2B x2D 3C x3E 7F As UTF8 1 in RFC 3629 except As UTF8 1 in RFC 3629 except NUL and NUL and UTF8 2 as defined in RFC 3629 STD 63 UTF8 2 as defined in RFC 3629 STD 63 UTF8 3 as defined in RFC 3629 STD 63 UTF8 3 as defined in RFC 3629 STD 63 UTF8 4 as defined in RFC 3629 STD 63 UTF8 4 as defined in RFC 3629 STD 63 UTF8 char safe UTF8 1 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 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname gs2 authzid a saslname GS2 has to transport an authzid since GS2 has to transport an authzid since the GSS API has no equivalent the GSS API has no equivalent gs2 std mech F gs2 nonstd flag F F means the mechanism is NOT is a F means the mechanism is not a standard GSS API mechanism in that the standard GSS API mechanism in that the RFC2743 section 3 1 header was missing RFC2743 section 3 1 header was missing gs2 cb flag n y p gs2 cb flag p n y GS2 channel binding CB flag GS2 channel binding CB flag p client supports and used CB n client does not support CB n client does not support CB y client supports CB thinks the server y client supports CB thinks the server does not does not p client supports and used CB gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid gs2 header gs2 std mech gs2 cb flag gs2 authzid The GS2 header is gs2 header 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 When the gs2 nonstd flag flag is present the client did not find data If the application did not provide channel binding data then remove a RFC2743 section 3 1 token header from the initial token the GS2 header is used as though it were application provided channel returned by GSS Init sec context This signals to the server that it binding data 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 The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 RFC3629 with three exceptions encoded using UTF 8 RFC3629 with three exceptions o The NUL characters is forbidden as required by section 3 4 1 of o The NUL characters is forbidden as required by section 3 4 1 of RFC4422 RFC4422 o The server MUST replace any comma in the string with 2C o The server MUST replace any occurance of comma in the string o The server MUST replace any equals in the string with 3D 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 If a server sends a string that does not conform to this syntax the client MUST reject authentication client MUST reject authentication 5 Channel Bindings 5 Channel Bindings If the server supports channel binding then it must list both forms If the server supports channel binding then it MUST list both forms of the SASL mechanism name for each GSS API mechanism supported via of the SASL mechanism name for each GSS API mechanism supported via GS2 i e GSS API mechanisms that support channel binding GS2 i e GSS API mechanisms that support channel binding If the client supports channel binding and the server does not i e 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 the server did not advertise the PLUS names then the client MUST either fail authentication or it MUST set the channel binding flag in either fail authentication or it MUST set the channel binding flag in the GS2 initial security context token to y and MUST NOT include the GS2 initial security context token to y and MUST NOT include application channel binding data in the GSS API channel binding input application channel binding data in the GSS API channel binding input to GSS Init sec context to GSS Init sec context If the client supports channel binding and the server also does then If the client supports channel binding and the server also does then the client MUST set the channel binding flag in the GS2 initial the client MUST set the channel binding flag in the GS2 initial security context token to p and MUST include application channel security context token to p and MUST include application channel binding data in the GSS API channel binding input to binding data in the GSS API channel binding input to GSS Init sec context 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 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 channel binding flag in the GS2 initial security context token to n and MUST NOT include application channel binding data in the GSS API and MUST NOT include application channel binding data in the GSS API channel binding input to GSS Init sec context channel binding input to GSS Init sec context Upon receipt of the initial authentication message the server checks Upon receipt of the initial authentication message the server checks the channel binding flag in the GS2 header and constructs a channel the channel binding flag in the GS2 header and constructs a channel binding data input for GSS Accept sec context accordingly If the binding data input for GSS Accept sec context accordingly If the client channel binding flag was n then the server MUST NOT include client channel binding flag was n then the server MUST NOT include application channel binding data in the GSS API channel binding input application channel binding data in the GSS API channel binding input to GSS Accept sec context If the client channel binding flag was to GSS Accept sec context If the client channel binding flag was y and the server does support channel binding then the server MUST y and the server does support channel binding then the server MUST fail authentication If the client channel binding flag was p the fail authentication If the client channel binding flag was p the server MUST include application channel binding data in the GSS API server MUST include application channel binding data in the GSS API channel binding input to GSS Accept sec context channel binding input to GSS Accept sec context For more discussions of channel bindings and the syntax of the For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 channel binding data for various security protocols see RFC5056 6 Examples 6 Examples Example 1 a one round trip GSS API context token exchange no Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given channel binding optional authzid given C Request authentication exchange C Request authentication exchange S Empty Challenge S Empty Challenge C na uthzid someuser initial context token with standard C na someuser initial context token with standard header removed header removed S Send reply context token as is S Send reply context token as is C Empty message C Empty message S Outcome of authentication exchange S Outcome of authentication exchange Example 2 a one and one half round trip GSS API context token Example 2 a one and one half round trip GSS API context token exchange exchange C Request authentication exchange C Request authentication exchange S Empty Challenge S Empty Challenge C na uthzid someuser initial context token with standard C na someuser initial context token with standard header removed header removed S Send reply context token as is S Send reply context token as is C Send reply context token as is C Send reply context token as is S Outcome of authentication exchange S Outcome of authentication exchange Example 3 a two round trip GSS API context token exchange no Example 3 a two round trip GSS API context token exchange standard token header C Request authentication exchange C Request authentication exchange S Empty Challenge S Empty Challenge C nauthzid someuser initial context token with standard C Fna someuser initial context token without header removed standard header S Send reply context token as is S Send reply context token as is C Send reply context token as is C Send reply context token as is S Send reply context token as is S Send reply context token as is C Empty message C Empty message S Outcome of authentication exchange S Outcome of authentication exchange Example 4 using channel binding Example 4 using channel binding C Request authentication exchange C Request authentication exchange S Empty Challenge S Empty Challenge C yauthzid someuser initial context token with standard C pa someuser initial context token with standard header removed header removed S Send reply context token as is S Send reply context token as is GSS API authentication is always initiated by the client The SASL GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from challenge zero byte string if it has not yet received a token from the client See section 3 of RFC4422 the client See section 3 of RFC4422 7 Authentication Conditions 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following Authentication MUST NOT succeed if any one of the following conditions are true conditions are true o GSS Init Accept sec context return anything other than o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE GSS S CONTINUE NEEDED or GSS S COMPLETE o If the client s GS2 channel binding flag was y and the server o If the client s GS2 channel binding flag was y and the server supports channel binding supports channel binding o If the client requires use of channel binding and the server did o If the client requires use of channel binding and the server did not advertise support for channel binding not advertise support for channel binding o Authorization of client principal i e src name in o Authorization of client principal i e src name in GSS Accept sec context to requested authzid failed GSS Accept sec context to requested authzid failed o If the client is not authorized to the requested authzid or an o If the client is not authorized to the requested authzid or an authzid could not be derived from the client s initiator principal authzid could not be derived from the client s initiator principal name name 8 GSS API Parameters 8 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the GS2 does not use any GSS API per message tokens Therefore the setting of req flags related to per message tokens is irrelevant setting of req flags related to per message tokens is irrelevant 9 Naming 9 Naming There s no requirement that any particular GSS API name types be There s no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor used However typically SASL servers will have host based acceptor principal names see RFC2743 section 4 1 and clients will principal names see RFC2743 section 4 1 and clients will typically have username initiator principal names see RFC2743 typically have username initiator principal names see RFC2743 section 4 2 section 4 2 10 GSS Mechanism SASLname call 10 GSS Inquire SASLname for mech call To allow SASL implementations to query for the SASL mechanism name of 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 a GSS API mechanism we specify a new GSS API function for this purpose purpose Inputs Inputs o desired mech OBJECT IDENTIFIER o desired mech OBJECT IDENTIFIER Outputs Outputs o sasl mech name OCTET STRING SASL name for this mechanism o sasl mech name UTF 8 STRING SASL name for this mechanism really ASCII o mech name UTF 8 STRING name of this mechanism possibly o mech name UTF 8 STRING name of this mechanism possibly localized localized o mech description UTF 8 STRING possibly localized o mech description UTF 8 STRING possibly localized description of this mechanism description of this mechanism Return major status codes Return major status codes o GSS S COMPLETE indicates successful completion and that output o GSS S COMPLETE indicates successful completion and that output parameters holds correct information parameters holds correct information o GSS S BAD MECH indicates that a d is red mech was unsupported by o GSS S BAD MECH indicates that a d esi red mech was unsupported by the GSS API implementation the GSS API implementation The GSS Mechanism SASLname call is used to get the SASL mechanism The GSS Inquire SASLname for mech call is used to get the SASL name for a GSS API mechanism It also returns a name and mechanism name for a GSS API mechanism It also returns a name description of the mechanism in a human readable form and description of the mechanism in a human readable form 10 1 gss mechanism saslname 10 1 gss inquire saslname

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

  • Diff: draft-ietf-sasl-gs2-10.txt - draft-ietf-sasl-gs2-11.txt
    of the length integers is longer than the entire message size minus 8 octets for the length fields the message is invalid During any successful authentication exchange the client and server will each send exactly one non empty Wrap token Conforming implementations MUST NOT send additional data after the above message syntax and MUST ignore additional data To illustrate implementations MUST NOT assume that the last Wrap token length octets of the packet correspond to the Wrap token because that would be incorrect if the packet contained additional data not described by this document 4 2 Context Token Field The format of the Context token field inside the SASL token is defined by each GSS API mechanism and the data is computed by for the client GSS Init sec context and for the server GSS Accept sec context 4 2 1 Client side The client calls GSS Init sec context passing in input context handle of GSS C NO CONTEXT initially mech type of the GSSAPI mechanism for which this SASL mechanism is registered the chan binding is set to NULL and targ name equal to output name from GSS Import Name called with input name type of GSS C NT HOSTBASED SERVICE and input name string of service hostname where service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server Clients MAY use name types other than GSS C NT HOSTBASED SERVICE to import servers acceptor names but only when they have a priori knowledge that the servers support alternate name types Otherwise clients MUST use GSS C NT HOSTBASED SERVICE for importing acceptor names When calling the GSS Init sec context the client SHOULD pass the integ req flag of TRUE but MAY set it to FALSE see section 10 below If the client intends to request a security layer it MUST also supply to the GSS Init sec context a mutual req flag of TRUE and a sequence req flag of TRUE If the client will be requesting a security layer providing confidentiality protection it MUST also supply to the GSS Init sec context a conf req flag of TRUE The client then responds with any resulting output token If GSS Init sec context returns GSS S CONTINUE NEEDED then the client expect the server to issue a token in a subsequent challenge or as additional information to the outcome of the authentication The client pass the context token to another call to GSS Init sec context repeating the procedure until GSS S COMPLETE is returned or authentication is aborted If the server sent a non empty Wrap token the context token is processed before processing the other tokens This is required because GSS Unwrap may need the context to be in the state it is after the Context token in the message has been processed When GSS Init sec context returns GSS S COMPLETE the client MUST examine the context to ensure that it provides a level of protection permitted by the client s security policy 4 2 2 Server side The server passes the first context token to GSS Accept sec context as input token setting input context handle to GSS C NO CONTEXT initially the chan binding set to NULL and a suitable acceptor cred handle see below Servers SHOULD use a credential obtained by calling GSS Acquire cred or GSS Add cred for the GSS C NO NAME desired name and the OID of the GSS API mechanism for which this SASL mechanism is registered Servers MAY use GSS C NO CREDENTIAL as an acceptor credential handle Servers MAY use a credential obtained by calling GSS Acquire cred or GSS Add cred for the server s principal name s and the GSS API mechanism for which this SASL mechanism is registered Unlike GSS Add cred the GSS Acquire cred uses an OID set of GSS API mechanism as an input parameter The OID set can be created by using GSS Create empty OID set and GSS Add OID set member It can be freed by calling the GSS Release oid set Use of server s principal names having GSS C NT HOSTBASED SERVICE name type and service hostname format where service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server is RECOMMENDED The server name can be generated by calling GSS Import name with input name type of GSS C NT HOSTBASED SERVICE and input name string of service hostname The server then responds with any resulting output token The server pass any resulting challenge from the client to another call to GSS Accept sec context repeating the procedure until GSS S COMPLETE is returned or authentication is aborted If the client sent a non empty Wrap token the context token is processed first Upon successful establishment of the security context i e GSS Accept sec context returns GSS S COMPLETE the server SHOULD verify that the negotiated GSS API mechanism is indeed the registered one This is done by examining the value of the mech type parameter returned from the GSS Accept sec context call If the value differ the SASL authentication MUST be aborted Upon successful establishment of the security context and if the server used GSS C NO NAME GSS C NO CREDENTIAL to create acceptor credential handle the server SHOULD also check using the GSS Inquire context that the target name used by the client matches the GSS C NT HOSTBASED SERVICE service hostname name syntax where service is the service name specified in the application protocol s profile and hostname is the fully qualified host name of the server When GSS Accept sec context returns GSS S COMPLETE the server MUST examine the context to ensure that it provides a level of protection permitted by the server s security policy 4 3 Wrap Token Field The Wrap token field MUST NOT be sent or received before the PROT READY flag is set locally by GSS Init sec context or Gss Accept sec context or if the PROT READY flag is never set before the context has been fully established The Wrap token field does not have to be present directly when the PROT READY flag is set During any exchange exactly one Wrap token field is sent in each direction The GS2 Wrap function is defined below and its inputs MUST follow the format described below If not exactly one Wrap token is received by the client and by the server the authentication MUST fail If PROT READY is never set by GSS Init sec context or GSS Accept sec context the flag is implied by successful context negotiation This is for GSS API v1 mechanisms that do not support PROT READY or for GSS API mechanism that do not provide per message protection This may result in a SASL token consisting of a context token length of 0 and a Wrap token The entity that sends the first Wrap token will have to specify a bitmap of supported and preferred quality of protection schemes The entity that replies to the Wrap tokens will pick a scheme based on the bitmask and local policy The quality of protection values are defined in section 9 Two pairs of input formats to the GS2 Wrap function are defined The first pair is used when the client sends the Wrap token first and the server responds The other pair is used when the server sends the 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 All the SASL authentication messages exchanged are exactly the same 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 as the security context tokens of the GSS API mechanism except for the initial security context token client qops client maxbuf channel binding length client cbqops channel binding data authzid The client qops integer indicate the client s preferred quality of Also the server SHOULD refrain from sending GSS API error tokens protection if channel bindings are absent or the negotiation of the tokens output by GSS Init sec context or GSS Accept sec context channel binding fails The quality of protection values are defined along with a major status code other than GSS S COMPLETE or in section 9 GSS S CONTINUE NEEDED as SASL applications handle error conditions The client maxbuf field indicate the maximum protected buffer size The initial security context token is modified as follows the client can receive in network byte order It MUST be 0 if the o The RFC2743 section 3 1 initial context token header MUST be client doesn t advertise support for any security layer the server removed if present and its presence is noted see below On the MUST verify this Small values can make it impossible for the server server side this header MUST be recomputed and restored prior to to send any protected message to the client due to the overhead passing the token to GSS Accept sec context added by GSS Wrap and the server MAY reject the authentication if it o A GS2 header MUST be prefixed to the resulting initial context detects this situation token This header has the form given below in ABNF RFC5234 The channel binding length is a network byte order integer that UTF8 1 safe x01 2B x2D 3C x3E 7F indicate the length of the channel binding data field As UTF8 1 in RFC 3629 except NUL and UTF8 2 as defined in RFC 3629 STD 63 UTF8 3 as defined in RFC 3629 STD 63 UTF8 4 as defined in RFC 3629 STD 63 UTF8 char safe UTF8 1 UTF8 2 UTF8 3 UTF8 4 The optional field client cbqops is present only if saslname 1 UTF8 char safe 2C 3D channel binding length is non zero and indicate the client s gs2 authzid a saslname preferred quality of protection if channel binding negotiation GS2 has to transport an authzid since succeeds The quality of protection values are defined in section 9 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 optional field channel binding data is present only if The GS2 header is also prepended to the application s channel binding channel binding length is non zero and contain the actual channel 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 binding data The optional field authzid contain the authorization identity The The gs2 authzid holds the SASL authorization identity It is authorization identity is encoded using UTF 8 RFC3629 The encoded using UTF 8 RFC3629 with three exceptions authorization identity is not terminated with the NUL U 0000 o The NUL characters is forbidden as required by section 3 4 1 of character Servers MUST validate that the authorization identity is RFC4422 valid UTF 8 4 3 3 Server last GS2 Wrap input The input to GS2 Wrap when the server sends a Wrap token field after receiving the Wrap token in the previous section from the client is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 server qop server maxbuf The server qop field integer indicate the selected quality of protection The quality of protection values are defined in section 9 The server maxbuf field indicate the maximum protected data buffer size the server can receive in network byte order It MUST be 0 if the server doesn t advertise support for any security layer the client MUST verify this Small values can make it impossible for the client to send any protected message to the server due to the overhead added by GSS Wrap and the client MAY reject the authentication if it detects this situation 4 3 4 Server first GS2 Wrap input The input to GS2 Wrap when the server sends the Wrap token first is as follows 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 o The server MUST replace any occurance of comma in the string binding data with 2C o The server MUST replace any occurance of comma in the string with 3D 4 3 5 Client last GS2 Wrap input If a server sends a string that does not conform to this syntax the client MUST reject authentication The input to GS2 Wrap when the clients sends a Wrap token field 5 Channel Bindings 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 If the server supports channel binding then it must list both forms 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 of the SASL mechanism name for each GSS API mechanism supported via GS2 i e GSS API mechanisms that support channel binding client qop client maxbuf authzid The client qop field is the selected quality of protection The If the client supports channel binding and the server does not i e quality of protection values are defined in section 9 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 The client maxbuf and authzid fields are as above 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 5 Channel Bindings 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 The GS2 mechanism provide its own channel binding mechanism instead Upon receipt of the initial authentication message the server checks of using the chan binding parameter in the GSS API context the channel binding flag in the GS2 header and constructs a channel functions The reason for this is that the GS2 mechanism provide an binding data input for GSS Accept sec context accordingly If the option to proceed even if the channel bindings does not match The client channel binding flag was n then the server MUST NOT include GSS API framework specifies that authentication cannot proceed if application channel binding data in the GSS API channel binding input channel bindings do not match 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 Client and servers MUST set the chan binding parameter in the calls For more discussions of channel bindings and the syntax of the to GSS Init sec context and GSS Accept sec context respectively to channel binding data for various security protocols see RFC5056 NULL Implementations SHOULD set the client cbqops and server cbqops to 6 Examples 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 Example 1 a one round trip GSS API context token exchange no frameworks and mechanisms that support channel binding MUST channel binding optional authzid given 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 C Request authentication exchange should provide better performance than using SASL security layers S Empty Challenge over secure channels and better security characteristics than using C nauthzid someuser initial context token with standard no SASL security layers over secure channels without channel binding header removed S Send reply context token as is C Empty message S Outcome of authentication exchange For more discussions of channel bindings and the syntax of the Example 2 a one and one half round trip GSS API context token channel binding data for various security protocols see RFC5056 exchange 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 6 Protocol Overview C Request authentication exchange S Empty Challenge C nauthzid someuser initial context token with standard header removed S Send reply context token as is C Send reply context token as is S Outcome of authentication exchange This section describe several high level protocol exchanges The Example 3 a two round trip GSS API context token exchange 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 C Request authentication exchange below GS2 Wrap refer to the operation of calling GS2 Wrap on the S Empty Challenge indicated fields formatted in the structures described earlier C nauthzid someuser initial context token with standard GSS Init sec context and GSS Accept sec context refer to the context header removed token generated by calling the respective function The GS2 SASL S Send reply context token as is Message is denoted as Context token Wrap token and the length C Send reply context token as is fields are not mentioned S Send reply context token as is C Empty message S Outcome of authentication exchange An authentication exchange using GS2 may look like Example 4 using channel binding C Request authentication exchange C Request authentication exchange S Empty Challenge S Empty Challenge C Send GSS Init sec context token C yauthzid someuser initial context token with standard header removed S After PROT READY is set S Send reply context token as is 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 GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from challenge zero byte string if it has not yet received a token from the client See section 3 of RFC4422 the client See section 3 of RFC4422 The next example illustrate when the client sends its Wrap token 7 Authentication Conditions first C Request authentication exchange Authentication MUST NOT succeed if any one of the following S Empty Challenge conditions are true 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 o GSS Init Accept sec context return anything other than the first empty message can be optimized away and then the protocol GSS S CONTINUE NEEDED or GSS S COMPLETE exchange will look like 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 C Request authentication exchange and 8 GSS API Parameters 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 GS2 does not use any GSS API per message tokens Therefore the indicating the outcome of the authentication then the protocol setting of req flags related to per message tokens is irrelevant exchange will look like C Request authentication exchange and 9 Naming 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 There s no requirement that any particular GSS API name types be GS2 Wrap message will be sent after the context has been established used However typically SASL servers will have host based acceptor The protocol may look like principal names see RFC2743 section 4 1 and clients will typically have username initiator principal names see RFC2743 section 4 2 C Request authentication exchange 10 GSS Mechanism SASLname call 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 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 C Request authentication exchange Inputs 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 o desired mech OBJECT IDENTIFIER 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 Outputs 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 o sasl mech name OCTET STRING SASL name for this mechanism PROT READY flag is set in the client after the first call to really ASCII GSS Init sec context and the server can send additional data to the client when indicating successful authentication the following protocol exchange will occur C Request authentication exchange and o mech name UTF 8 STRING name of this mechanism possibly send GSS Init sec context localized 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 o mech description UTF 8 STRING possibly localized authentication possible using this protocol description of this mechanism 7 Authentication Conditions Return major status codes Authentication MUST NOT succeed if any one of the following o GSS S COMPLETE indicates successful completion and that output conditions are true parameters holds correct information o An invalid SASL token is received e g length field checks o GSS S BAD MECH indicates that a disred mech was unsupported by discussed in section 4 1 fail the GSS API implementation o GSS Init Accept sec context return anything other than The GSS Mechanism SASLname call is used to get the SASL mechanism GSS S CONTINUE NEEDED or GSS S COMPLETE name for a GSS API mechanism It also returns a name and description of the mechanism in a human readable form o GSS Wrap returns anything other than GSS S COMPLETE 10 1 gss mechanism saslname o GSS Unwrap returns anything other than GSS S COMPLETE There The C binding for the GSS Mechanism SASLname call is as follows 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 OM uint32 gss mechanism saslname too short invalid maximum buffer size as the expected Wrap OM uint32 minor status token const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description o Local policy reject the attempt For example client and server Purpose can t agree on qop proposal or channel binding negotiation failed o server side Authorization of client principal i e src name in Output the SASL mechanism name of a GSS API mechanism Also output GSS Acecpt sec context to requested authzid failed a name and description of the mechanism in a human readable form 8 GSS API Parameters Parameters The implementation MAY set any GSSAPI flags or arguments not minor status Integer modify mentioned in this specification as is necessary for the Mechanism specific status code implementation to enforce its security policy 9 Security Layer Bits Function value GSS status code The fields client qops server qops client cbqops and GSS S COMPLETE Successful completion 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 GSS S BAD MECH The desired mech OID is unsupported layer Note that client qop and server qop MAY indicate a quality of 11 GSS Inquire mech for SASLname call 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 To allow SASL clients to more efficiently identify which GSS API influence the security layer selection The most significant bit is mechanism a particular SASL mechanism name refers to we specify a new used to signal failed channel binding negotiation Implementations GSS API utility function for this purpose MUST set the bit if channel bindings were provided from the other end and a local channel binding is absent or not equal Implementation MUST clear the bit otherwise The security layers and their corresponding bit masks are as follow s Input s 1 No security layer o sasl mech name OCTET STRING SASL name of mechanism 2 Integrity protection really ASCII Sender calls GSS Wrap with conf flag set to FALSE 4 Confidentiality protection Sender calls GSS Wrap with conf flag set to TRUE 8 64 Reserved 128 Channel binding negotiation failed The bit masks 8 64 are reserved and may be defined in the future Outputs bits which are not understood MUST be negotiated off When decoding any received data with GSS Unwrap the major status o mech type OBJECT IDENTIFIER must be explicit mechanism other than the GSS S COMPLETE MUST be treated as a fatal error and not default specifier For integrity and confidentiality protection GS2 negotiates the Return major status codes maximum size of the output message to send Implementations can use the GSS Wrap size limit call to determine the corresponding maximum size input message 9 1 Examples o GSS S COMPLETE indicates successful completion and that output parameters holds correct information When no security layer is negotiated the octet will encode an integer o GSS S BAD MECH indicates that no supported GSS API mechanism 1 as follows had the indicated sasl mech name 7 6 5 4 3 2 1 0 The GSS Inquire mech for SASLname call is used to get the GSS API mechanism OID associated with a SASL mechanism name 0 0 0 0 0 0 0 1 When integrity is negotiated the octet will encode an integer 2 as 11 1 gss inquire mech for saslname The C binding for the GSS Inquire mech for SASLname call is as follows follows 7 6 5 4 3 2 1 0 OM uint32 gss inquire mech for saslname OM uint32 minor status 0 0 0 0 0 0 1 0 const gss buffer t sasl mech name gss OID mech type When confidentiality is negotiated and channel binding negotiation Purpose failed the octet will encode an integer 128 4 132 as follows 7 6 5 4 3 2 1 0 Output GSS API mechanism OID of mechanism associated with given sasl mech name 1 0 0 0 0 1 0 0 When a bitmask that indicates that all security layers are Parameters acceptable the octet will encode an integer 1 2 4 7 as follows 7 6 5 4 3 2 1 0 minor status Integer modify Mechanism specific status code 0 0 0 0 0 1 1 1 10 Non integrity capable GSS API mechanisms Function value GSS status code Mechanisms that do not support integrity can be used with GS2 but GSS S COMPLETE Successful completion some security features cannot be provided in particular including channel bindings security layers and integrity protection of the authorization identity Channel bindings and security layers MUST NOT be negotiated when the GSS S BAD MECH The desired mech OID is unsupported GSS API mechanism do not support integrity It should also be understood that the authorization identity is not integrity protected Whether a mechanism supports integrity or not for the purpose of 12 Security Layers GS2 is decided by whether the integ avail output variable from GSS Init sec context for clients and GSS Accept sec context for servers If integ avail is FALSE integrity is not supported There is a potential interoperability problem if a client call GS2 does not currently support SASL security layers Applications GSS Init sec context with integ req flag of TRUE and the context that need integrity protection or confidentiality and integrity negotiation fails because the mechanism due to design the protection MUST use either channel binding to a secure external capability of the credentials or policy cannot provide per message channel or a SASL mechanism that does provide security layers protection Calling GSS Init sec context with a FALSE integ req flag instead is not optimal since a mechanism may then negotiate less security than it would have otherwise done It is RECOMMENDED that implementations only ever call NOTE WELL the GS2 client s first authentication message MUST always GSS Init sec context with a integ req flag of FALSE when it knows start with F n y or p otherwise the server MUST fail that the particular GSS API mechanism will not be able to negotiate authentication This will allow us to add support for security per message protection services 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 Implementations MAY have a policy to disallow non integrity capable A sketch of how to add sec layer support Add a way for the mechanisms and always call GSS Init sec context with the client to a make an offer of sec layers and max buffer b make an integ req flag set to TRUE 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 opportunistic proposal reply token prefixed with a byte indicating acceptance or reject it along with an indication of the server s acceptable sec layers

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

  • Diff: draft-ietf-sasl-gs2-09.txt - draft-ietf-sasl-gs2-10.txt
    6 9 11 22 13 15 11 12 16 17 13 10 16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10 base32 encoding base32 encoding Q L J H G J L W N P L M Q R N K Q L J H G J L W N P L M Q R N K The last step translate each decimal value using table 3 in Base32 The last step translate each decimal value using table 3 in Base32 6 Thus the SASL mechanism name for the Kerberos V5 GSSAPI RFC4648 Thus the SASL mechanism name for the Kerberos V5 GSSAPI mechanism is GS2 QLJHGJLWNPLMQRNK mechanism is GS2 QLJHGJLWNPLMQRNK 4 SASL Authentication Exchange Message Format 4 SASL Authentication Exchange Message Format 4 1 SASL Messages 4 1 SASL Messages During the SASL authentication exchange for GS2 a number of messages During the SASL authentication exchange for GS2 a number of messages following the following format is sent between the client and server following the following format is sent between the client and server 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 skipping to change at page 13 line 23 skipping to change at page 13 line 23 The optional field client cbqops is present only if The optional field client cbqops is present only if channel binding length is non zero and indicate the client s channel binding length is non zero and indicate the client s preferred quality of protection if channel binding negotiation preferred quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 succeeds The quality of protection values are defined in section 9 The optional field channel binding data is present only if The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel channel binding length is non zero and contain the actual channel binding data binding data The optional field authzid contain the authorization identity The The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 5 The authorization authorization identity is encoded using UTF 8 RFC3629 The identity is not terminated with the NUL U 0000 character Servers authorization identity is not terminated with the NUL U 0000 MUST validate that the authorization identity is valid UTF 8 character Servers MUST validate that the authorization identity is valid UTF 8 4 3 3 Server last GS2 Wrap input 4 3 3 Server last GS2 Wrap input The input to GS2 Wrap when the server sends a Wrap token field after 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 receiving the Wrap token in the previous section from the client is as follows as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 skipping to change at page 15 line 22 skipping to change at page 15 line 22 channel bindings do not match channel bindings do not match Client and servers MUST set the chan binding parameter in the calls Client and servers MUST set the chan binding parameter in the calls to GSS Init sec context and GSS Accept sec context respectively to to GSS Init sec context and GSS Accept sec context respectively to NULL NULL Implementations SHOULD set the client cbqops and server cbqops to Implementations SHOULD set the client cbqops and server cbqops to no security layer and instead depend on the session security afforded no security layer and instead depend on the session security afforded by the bound in channel by the bound in channel In order to accomodate the requirement in 1 6 Authentication In order to accomodate the requirement in RFC505 6 Authentication frameworks and mechanisms that support channel binding MUST frameworks and mechanisms that support channel binding MUST communicate channel binding failure to applications implementations communicate channel binding failure to applications implementations MUST provide a way to communicate channel binding failures to assert a bit in the security layer bitmask see Section 9 on applications negotiation failures Use of no SASL security layers in combination with channel binding Use of no SASL security layers in combination with channel binding should provide better performance than using SASL security layers should provide better performance than using SASL security layers over secure channels and better security characteristics than using over secure channels and better security characteristics than using no SASL security layers over secure channels without channel binding no SASL security layers over secure channels without channel binding For more discussions of channel bindings and the syntax of the For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see 8 For channel binding data for various security protocols see RFC5056 easy reference the channel binding format used for The Transport For easy reference the channel binding format used for The Transport Layer Security TLS Protocol 14 is specified in 16 Layer Security TLS Protocol RFC4346 is specified in I D altman tls channel bindings 6 Protocol Overview 6 Protocol Overview This section describe several high level protocol exchanges The This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur examples and other exchanges are permitted and will occur skipping to change at page 16 line 44 skipping to change at page 16 line 44 GS2 Wrap client qop client maxbuf authzid GS2 Wrap client qop client maxbuf authzid S Send GSS Accept sec context token S Send GSS Accept sec context token C Send GSS Init sec context token C Send GSS Init sec context token S Outcome of authentication exchange S Outcome of authentication exchange GSS API authentication is always initiated by the client The SASL GSS API authentication is always initiated by the client The SASL framework allows either the client and server to initiate framework allows either the client and server to initiate authentication In GS2 the server will send an initial empty authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from challenge zero byte string if it has not yet received a token from the client See section 3 of 2 the client See section 3 of RFC442 2 The next example illustrate when the client sends its Wrap token The next example illustrate when the client sends its Wrap token first first C Request authentication exchange C Request authentication exchange S Empty Challenge S Empty Challenge C Send GSS Init sec context token C Send GSS Init sec context token C After PROT READY is set C After PROT READY is set send GSS Init sec context send GSS Init sec context skipping to change at page 20 line 27 skipping to change at page 20 line 27 o GSS Unwrap returns anything other than GSS S COMPLETE There o GSS Unwrap returns anything other than GSS S COMPLETE There can t be supplementary status codes in GS2 at this point so any can t be supplementary status codes in GS2 at this point so any indications of out of order processing or replays is fatal indications of out of order processing or replays is fatal o The token returned from GSS Unwrap fail to parse correctly e g o The token returned from GSS Unwrap fail to parse correctly e g too short invalid maximum buffer size as the expected Wrap too short invalid maximum buffer size as the expected Wrap token token o Local policy reject the attempt For example client and server o Local policy reject the attempt For example client and server can t agree on qop proposal can t agree on qop proposal or channel binding negotiation failed o server side Authorization of client principal i e src name in o server side Authorization of client principal i e src name in GSS Acecpt sec context to requested authzid failed GSS Acecpt sec context to requested authzid failed 8 GSS API Parameters 8 GSS API Parameters The implementation MAY set any GSSAPI flags or arguments not The implementation MAY set any GSSAPI flags or arguments not mentioned in this specification as is necessary for the mentioned in this specification as is necessary for the implementation to enforce its security policy implementation to enforce its security policy skipping to change at page 22 line 23 skipping to change at page 22 line 23 layer layer Note that client qop and server qop MAY indicate a quality of Note that client qop and server qop MAY indicate a quality of protection that was not offered by the server and client protection that was not offered by the server and client respectively This SHOULD only be used when the server or client respectively This SHOULD only be used when the server or client respectively would otherwise fail the entire authentication respectively would otherwise fail the entire authentication exchange The server client that receives a client qop exchange The server client that receives a client qop server qop MUST verify that it corresponds to an acceptable server qop MUST verify that it corresponds to an acceptable security level security level Whether the channel binding negotiation is successful or not may influence the security layer selection The most significant bit is used to signal failed channel binding negotiation Implementations MUST set the bit if channel bindings were provided from the other end and a local channel binding is absent or not equal Implementation MUST clear the bit otherwise The security layers and their corresponding bit masks are as follows The security layers and their corresponding bit masks are as follows 1 No security layer 1 No security layer 2 Integrity protection 2 Integrity protection Sender calls GSS Wrap with conf flag set to FALSE Sender calls GSS Wrap with conf flag set to FALSE 4 Confidentiality protection 4 Confidentiality protection Sender calls GSS Wrap with conf flag set to TRUE Sender calls GSS Wrap with conf flag set to TRUE 8 64 Reserved 128 Channel binding negotiation failed Other bit masks may be defined in the future bits which are not The bit masks 8 64 are reserved and may be defined in the future understood MUST be negotiated off bits which are not understood MUST be negotiated off When decoding any received data with GSS Unwrap the major status When decoding any received data with GSS Unwrap the major status other than the GSS S COMPLETE MUST be treated as a fatal error other than the GSS S COMPLETE MUST be treated as a fatal error For integrity and confidentiality protection GS2 negotiates the For integrity and confidentiality protection GS2 negotiates the maximum size of the output message to send Implementations can use maximum size of the output message to send Implementations can use the GSS Wrap size limit call to determine the corresponding maximum the GSS Wrap size limit call to determine the corresponding maximum size input message size input message 9 1 Examples 9 1 Examples When no security layer is negotiated the octet will encode an integer When no security layer is negotiated the octet will encode an integer 1 as follows 1 as follows 0 1 2 3 4 5 6 7 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 When integrity is negotiated the octet will encode an integer 2 as When integrity is negotiated the octet will encode an integer 2 as follows follows 0 1 2 3 4 5 6 7 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 When confidentiality is negotiated the octet will encode an integer 4 When confidentiality is negotiated and channel binding negotiation as follows failed the octet will encode an integer 128 4 132 as follows 0 1 2 3 4 5 6 7 7 6 5 4 3 2 1 0 0 0 0 0 0 1 0 0 1 0 0 0 0 1 0 0 When a bitmask that indicates that all security layers are acceptable the octet will encode an integer 1 2 4 7 as follows 7 6 5 4 3 2 1 0 0 0 0 0 0 1 1 1 10 Non integrity capable GSS API mechanisms 10 Non integrity capable GSS API mechanisms Mechanisms that do not support integrity can be used with GS2 but Mechanisms that do not support integrity can be used with GS2 but some security features cannot be provided in particular including some security features cannot be provided in particular including channel bindings security layers and integrity protection of the channel bindings security layers and integrity protection of the authorization identity authorization identity Channel bindings and security layers MUST NOT be negotiated when the Channel bindings and security layers MUST NOT be negotiated when the skipping to change at page 25 line 7 skipping to change at page 25 line 7 GSS Init sec context with a integ req flag of FALSE when it knows GSS Init sec context with a integ req flag of FALSE when it knows that the particular GSS API mechanism will not be able to negotiate that the particular GSS API mechanism will not be able to negotiate per message protection services per message protection services Implementations MAY have a policy to disallow non integrity capable Implementations MAY have a policy to disallow non integrity capable mechanisms and always call GSS Init sec context with the mechanisms and always call GSS Init sec context with the integ req flag set to TRUE integ req flag set to TRUE 11 Interoperability with the SASL GSSAPI mechanism 11 Interoperability with the SASL GSSAPI mechanism The Kerberos V5 GSS API 10 mechanism is currently used in SASL The Kerberos V5 GSS API RFC1964 mechanism is currently used in SASL under the name GSSAPI see GSSAPI mechanism 12 The Kerberos V5 under the name GSSAPI see GSSAPI mechanism RFC4752 The mechanism may also be used with the GS2 family This causes an Kerberos V5 mechanism may also be used with the GS2 family This interopability problem which is discussed and resolved below causes an interopability problem which is discussed and resolved below 11 1 The interoperability problem 11 1 The interoperability problem If a client or server only support Kerberos V5 under the GSSAPI If a client or server only support Kerberos V5 under the GSSAPI name and the server or client only support Kerberos V5 under the name and the server or client only support Kerberos V5 under the GS2 family the authentication negotiation will fail GS2 family the authentication negotiation will fail 11 2 Resolving the problem 11 2 Resolving the problem If the Kerberos V5 mechanism is supported under GS2 in a server the If the Kerberos V5 mechanism is supported under GS2 in a server the server SHOULD also support Kerberos V5 through the GSSAPI server SHOULD also support Kerberos V5 through the GSSAPI mechanism to avoid interoperability problems with older clients mechanism to avoid interoperability problems with older clients Reasons for violating this recommendation may include security Reasons for violating this recommendation may include security considerations regarding the absent features in the GS2 mechanism considerations regarding the absent features in the GS2 mechanism The Kerberos V5 GSSAPI SASL mechanism lack channel bindings which The Kerberos V5 GSSAPI SASL mechanism lack channel bindings which could enable certain tunnel attacks 18 could enable certain tunnel attacks mitm 11 3 Additional recommendations 11 3 Additional recommendations It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism rather than through the GSSAPI mechanism if both are available rather than through the GSSAPI mechanism if both are available because of the additional features in the GS2 mechanism because of the additional features in the GS2 mechanism 12 Mechanisms that negotiate other mechanisms 12 Mechanisms that negotiate other mechanisms A GSS API mechanism that negotiate other mechanisms interact badly A GSS API mechanism that negotiate other mechanisms interact badly skipping to change at page 26 line 34 skipping to change at page 26 line 34 negotiate mechanism X by using a GSS API mechanism that negotiate negotiate mechanism X by using a GSS API mechanism that negotiate other mechanisms such as SPNEGO it may end up using mechanism Z other mechanisms such as SPNEGO it may end up using mechanism Z when it ideally should

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

  • Diff: draft-ietf-sasl-gs2-08.txt - draft-ietf-sasl-gs2-09.txt
    do not match channel bindings do not match Client and servers MUST set the chan binding parameter in the calls Client and servers MUST set the chan binding parameter in the calls to GSS Init sec context and GSS Accept sec context respectively to to GSS Init sec context and GSS Accept sec context respectively to NULL NULL Implementations SHOULD set the client cbqops and server cbqops to Implementations SHOULD set the client cbqops and server cbqops to no security layer and instead depend on the session security afforded no security layer and instead depend on the session security afforded by the bound in channel 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 Use of no SASL security layers in combination with channel binding should provide better performance than using SASL security layers should provide better performance than using SASL security layers over secure channels and better security characteristics than using over secure channels and better security characteristics than using no SASL security layers over secure channels without channel binding no SASL security layers over secure channels without channel binding For more discussions of channel bindings and the syntax of the For more discussions of channel bindings and the syntax of the channel binding data for various security protocols see 8 For channel binding data for various security protocols see 8 For easy reference the channel binding format used for The Transport easy reference the channel binding format used for The Transport Layer Security TLS Protocol 14 is specified in 16 Layer Security TLS Protocol 14 is specified in 16 skipping to change at page 16 line 25 skipping to change at page 16 line 25 below GS2 Wrap refer to the operation of calling GS2 Wrap on the below GS2 Wrap refer to the operation of calling GS2 Wrap on the indicated fields formatted in the structures described earlier indicated fields formatted in the structures described earlier GSS Init sec context and GSS Accept sec context refer to the context GSS Init sec context and GSS Accept sec context refer to the context token generated by calling the respective function The GS2 SASL token generated by calling the respective function The GS2 SASL Message is denoted as Context token Wrap token and the length Message is denoted as Context token Wrap token and the length fields are not mentioned fields are not mentioned An authentication exchange using GS2 may look like An authentication exchange using GS2 may look like C Request authentication exchange C Request authentication exchange S Send token S Empty Challenge C Send GSS Init sec context token C Send GSS Init sec context token S After PROT READY is set S After PROT READY is set send GSS Accept sec context send GSS Accept sec context GS2 Wrap server qops server maxbuf GS2 Wrap server qops server maxbuf C After PROT READY is set C After PROT READY is set send GSS Init sec context send GSS Init sec context GS2 Wrap client qop client maxbuf authzid GS2 Wrap client qop client maxbuf authzid S Send GSS Accept sec context token S Send GSS Accept sec context token C Send GSS Init sec context token C Send GSS Init sec context token S Outcome of authentication exchange S Outcome of authentication exchange Because GSS API authentication is initiated by the client the length GSS API authentication is always initiated by the client The SASL field will be 0 in the initial token from the server to the client framework allows either the client and server to initiate when the protocol profile does not support additional information to authentication In GS2 the server will send an initial empty be sent together with the authentication request 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 The next example illustrate when the client sends its Wrap token first first C Request authentication exchange C Request authentication exchange S Send token S Empty Challenge C Send GSS Init sec context token C Send GSS Init sec context token C After PROT READY is set C After PROT READY is set send GSS Init sec context send GSS Init sec context GS2 Wrap client qops client maxbuf GS2 Wrap client qops client maxbuf channel binding length 0 authzid channel binding length 0 authzid S After PROT READY is set S After PROT READY is set send GSS Accept sec context send GSS Accept sec context GS2 Wrap server qop server maxbuf GS2 Wrap server qop server maxbuf skipping to change at page 20 line 10 skipping to change at page 20 line 10 as additional information as additional information The last example illustrate the optimal round trip wise The last example illustrate the optimal round trip wise authentication possible using this protocol authentication possible using this protocol 7 Authentication Conditions 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following Authentication MUST NOT succeed if any one of the following conditions are true conditions are true o An invalid SASL token is received i e length shorter than 4 o An invalid SASL token is received e g length field checks octets discussed in section 4 1 fail o GSS Init Accept sec context return anything other than o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Unwrap returns anything other than GSS S COMPLETE There o GSS Unwrap returns anything other than GSS

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

  • Diff: draft-ietf-sasl-gs2-07.txt - draft-ietf-sasl-gs2-08.txt
    10 26 26 19 30 0 15 21 26 15 24 3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24 Translating each decimal value using table 3 in Base32 6 yields the base32 encoding character sequence DT4PIK22T6APV2PY Thus the SASL mechanism name for the SPKM 1 GSSAPI mechanism is GS2 DT4PIK22T6APV2PY D T 4 P I K 2 2 T 6 A P V 2 P Y The last step translate each decimal value using table 3 in Base32 6 Thus the SASL mechanism name for the SPKM 1 GSSAPI mechanism is GS2 DT4PIK22T6APV2PY The OID for the Kerberos V5 GSS API mechanism 10 is The OID for the Kerberos V5 GSS API mechanism 10 is 1 2 840 113554 1 2 2 and its DER encoding is in hex 06 09 2A 86 48 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 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 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 binary and re group them in groups of 5 and convert them back to decimal which results in these computations decimal which results in these computations hex hex 82 d2 73 25 76 6b d6 c8 45 aa 82 d2 73 25 76 6b d6 c8 45 aa skipping to change at page 7 line 28 skipping to change at page 7 line 32 10000010 11010010 01110011 00100101 01110110 10000010 11010010 01110011 00100101 01110110 01101011 11010110 11001000 01000101 10101010 01101011 11010110 11001000 01000101 10101010 binary in groups of 5 binary in groups of 5 10000 01011 01001 00111 00110 01001 01011 10110 10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011 01100 10000 10001 01101 01010 01101 01111 01011 01100 10000 10001 01101 01010 decimal of each group decimal of each group 16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10 16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10 Translating each decimal value using table 3 in Base32 6 yields the base32 encoding character sequence QLJHGJLWNPLNQRNK Thus the SASL mechanism name Q L J H G J L W N P L M Q R N K for the Kerberos V5 GSSAPI mechanism is GS2 QLJHGJLWNPLNQRNK The last step translate each decimal value using table 3 in Base32 6 Thus the SASL mechanism name for the Kerberos V5 GSSAPI mechanism is GS2 QLJHGJLWNPLMQRNK 4 SASL Authentication Exchange Message Format 4 SASL Authentication Exchange Message

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



  •