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".
  • Index of /cl2html
    Parent Directory cl2html 2015 08 11 20 46 7 1K cl2html pl 2015 08 11 20 46 7 1K cvsactivity html 2015 08 11 20 46 4 9K index shtml 2015 08 11 20 46 2 0K Apache 2 4

    Original URL path: http://www.josefsson.org/cl2html/ (2016-04-30)
    Open archived version from archive


  • krb5dissect
    highly portable and only require an ANSI C89 platform If you want help with using or adapting this implementation on a commercial basis please contact me Krb5dissect is licensed under the GNU General Public License What s new See the NEWS file from live sources Documentation There is a man page included in the distribution The formats are documented in ccache txt and keytab txt Download The releases are distributed from the release directory All releases are signed with an OpenPGP key with fingerprint 0xB565716F Examples Basic invocation jas mocca krb5dissect krb5dissect 2 1 Copyright C 2007 Simon Josefsson This is free software You may redistribute copies of it under the terms of the GNU General Public License There is NO WARRANTY to the extent permitted by law Written by Simon Josefsson krb5dissect 2 1 Display Kerberos 5 credentials read from FILE in text form When FILE is read standard input Supported formats are the version 0x0502 Kerberos 5 keytab and the version 0x0504 Kerberos 5 ccache Keytabs are typically stored in etc krb5 keytab and ccache in tmp krb5cc UID The tool automatically detect the format and selects the appropriate decoder Usage krb5dissect OPTIONS FILE h help Print help and exit V version Print version and exit k keytab Read from etc krb5 keytab instead of stdin c ccache Read from tmp krb5cc UID instead of stdin quiet Don t print initial banner default off jas mocca Print the contents of the host s etc krb5 keytab dopio krb5dissect quiet keytab file format version 0502 Keytab entry 0 size 003d num components 9ff4 num components 0002 realmlen 0013 realm DOPIO JOSEFSSON ORG componentlen 0004 component host componentlen 0005 component dopio name type 0001 key vno8 0001 keytype 0003 keylen 0008 key value 0123 vno 0001 dopio Print the contents

    Original URL path: http://www.josefsson.org/krb5dissect/ (2016-04-30)
    Open archived version from archive

  • Pictures I've taken
    boring at all Thank you for those beautiful pictures you are willing to share with the world Daniella San Diego December 10 15 2000 Washington D C April 21 28 2001 Singapore 9 15 June 2001 Santiago de Chile 12 July 2001 Peru 13 24 July 2001 New York 25 July 2001 London 5 10 August 2001 Berlin 2 7 December 2001 Rome 20 25 March 2002 Sweden 11 25

    Original URL path: http://www.josefsson.org/travel/ (2016-04-30)
    Open archived version from archive


  • mechanism except for the initial security context token The client and server MAY send GSS API error tokens tokens output by GSS Init sec context or GSS Accept sec context when the major status code is other than GSS S COMPLETE or GSS S CONTINUE NEEDED As this indicates an error condition after sending the token the sending side should fail the authentication The initial security context token is modified as follows o The initial context token header see Section 3 1 of RFC2743 MUST be removed if present If the header is not present the client MUST send a gs2 nonstd flag flag see below On the server side this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context except when the gs2 nonstd flag is sent o A GS2 header MUST be prefixed to the resulting initial context token This header has the form gs2 header given below in ABNF RFC5234 Josefsson Expires September 4 2014 Page 8 Internet Draft SASL GS2 March 2014 The figure below describes the permissible attributes their use and the format of their values All attribute names are single US ASCII letters and are case sensitive UTF8 1 safe x01 2B x2D 3C x3E 7F As UTF8 1 in RFC 3629 except NUL and UTF8 2 UTF8 3 UTF8 4 UTF8 char safe UTF8 1 safe UTF8 2 UTF8 3 UTF8 4 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname GS2 has to transport an authzid since the GSS API has no equivalent gs2 nonstd flag F F means the mechanism is not a standard GSS API mechanism in that the RFC 2743 Section 3 1 header was missing cb name 1 ALPHA DIGIT See RFC 5056 Section 7 gs2 cb flag p cb name n y GS2 channel binding CB flag p client supports and used CB n client does not support CB y client supports CB thinks the server does not gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid The GS2 header is gs2 header When the gs2 nonstd flag flag is present the client did not find remove a token header RFC2743 Section 3 1 from the initial token returned by GSS Init sec context This signals to the server that it MUST NOT re add the data that is normally removed by the client The gs2 cb flag signals the channel binding mode One of p n or y is used A p means the client supports and used a channel binding and the name of the channel binding type is indicated An n means that the client does not support channel binding A y means the client supports channel binding but believes the server does not support it so it did not use a channel binding See the next section for more details The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 RFC3629 with three exceptions Josefsson Expires September 4 2014 Page 9 Internet Draft SASL GS2 March 2014 o The NUL character is forbidden as required by section 3 4 1 of RFC4422 o The server MUST replace any comma in the string with 2C o The server MUST replace any equals in the string with 3D Upon receipt of this value the server verifies its correctness according to the used SASL protocol profile Failed verification results in a failed authentication exchange 5 Channel Bindings GS2 supports channel binding to external secure channels such as TLS Clients and servers may or may not support channel binding therefore the use of channel binding is negotiable However GS2 does not provide security layers therefore it is imperative that GS2 provide integrity protection for the negotiation of channel binding Use of channel binding is negotiated as follows o Servers that support the use of channel binding SHOULD advertise both the non PLUS and PLUS variant of each GS2 mechanism name If the server cannot support channel binding it SHOULD advertise only the non PLUS variant If the server would never succeed in the authentication of the non PLUS variant due to policy reasons it MUST advertise only the PLUS variant o If the client supports channel binding and the server does not appear to i e the client did not see the PLUS name advertised by the server then the client MUST NOT use an n gs2 cb flag o Clients that support mechanism negotiation and channel binding MUST use a p gs2 cb flag when the server offers the PLUS variant of the desired GS2 mechanism o If the client does not support channel binding then it MUST use an n gs2 cb flag Conversely if the client requires the use of channel binding then it MUST use a p gs2 cb flag Clients that do not support mechanism negotiation never use a y gs2 cb flag they use either p or n according to whether they require and support the use of channel binding or whether they do not respectively o The client generates the chan bindings input parameter for GSS Init sec context as described below o Upon receipt of the initial authentication message the server checks the gs2 cb flag in the GS2 header and constructs a chan bindings parameter for GSS Accept sec context as described below If the client channel binding flag was y and the server did advertise support for channel bindings by advertising the PLUS variant of the mechanism chosen by the client then the server MUST fail authentication If the client channel binding flag was p and the server does not support the indicated channel Josefsson Expires September 4 2014 Page 10 Internet Draft SASL GS2 March 2014 binding type then the server MUST fail authentication o If the client used an n gs2 cb flag and the server requires the use of channel binding then the server MUST fail authentication FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION n no support N A If server disallows non channel bound authentication then fail y Yes not required No Authentication may succeed CB not used y Yes not required Yes Authentication must fail p Yes Yes Authentication may succeed with CB used p Yes No Authentication will fail N A Yes required No Client does not even try For more discussion of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 5 1 Content of GSS CHANNEL BINDINGS Structure The calls to GSS Init sec context and GSS Accept sec context take a chan bindings parameter The value is a GSS CHANNEL BINDINGS structure RFC5554 The initiator address type and acceptor address type fields of the GSS CHANNEL BINDINGS structure MUST be set to 0 The initiator address and acceptor address fields MUST be the empty string The application data field MUST be set to the gs2 header excluding the initial gs2 nonstd flag part concatenated with when a gs2 cb flag of p is used the application s channel binding data 5 2 Default Channel Binding A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows tls unique is the default channel binding type for any application Josefsson Expires September 4 2014 Page 11 Internet Draft SASL GS2 March 2014 that doesn t specify one Servers MUST implement the tls unique RFC5929 channel binding type if they implement any channel binding Clients SHOULD implement the tls unique channel binding type if they implement any channel binding Clients and servers SHOULD choose the highest layer innermost end to end TLS channel as the channel to which to bind Servers MUST choose the channel binding type indicated by the client or fail authentication if they don t support it 6 When the mechanism does not support channel binding and or mutual authentication Some authentication mechanisms does not offer mutual authentication or is unable to provide channel bindings This is unfortunate and usually suggests that the authentication mechanism offers limited authentication functionality However there are situations when the lack of this functionality can be mitigated with other protection mechanisms leading to acceptable overall security Being able to define and use an authentication mechanism as a GSS API mechanism and then use that GSS API mechanism in the SASL environment using GS2 has advantages for example being able to re use existing generic GS2 implementations Further being able to express all mechanisms that can be expressed as a GSS API mechanisms as a SASL mechanism and vice versa provides design elegance and framework replacability Therefor this document relaxes the requirement that the GSS API mechanism support channel bindings and or mutual authentication Implementing and deploying applications that supports those mechanism require some consideration and this section discuss the relevant areas For the discussion it helps to understand what happens with the GS2 bridge when a GSS API mechanism does not offer channel bindings or mutual authentication When channel bindings is not supported by the underlying mechanism GS2 cannot protect its data essentially the channel binding flag and the SASL authorization identity This means that the security of the channel binding mode breaks down and that the other side cannot trust the SASL authorization identity When mutual authentication is not happening the client cannot know that it sends its data to the intended server It is acceptable to use these mechanisms with GS2 in some situations For example if the client uses TLS against a server and the client verify the server s certificate properly so that server authentication has occured then authenticating the client to the Josefsson Expires September 4 2014 Page 12 Internet Draft SASL GS2 March 2014 server using a weak GSS API mechanism will technically work The security properties will not be as good as they would have been if the underlying mechanism supported channel binding or mutual authentication however they become as good as possible This document relaxes the requirements on GSS API mechanism so that all GSS API mechanism can be expressed in GS2 For these mechanisms the gs2 cb flag value MUST always be n and the PLUS variant of the GS2 mechanism name MUST NOT be advertised or negotiated The SAML SASL bridge RFC6595 and the SAML OpenID bridge RFC6616 are two examples of documents that describe such bridges These documents did not meet the requirements of the original GS2 bridge but with the update in this document they are conformant Note that both documents had discussions describing this aspect and sufficient requirements for safe implementation and deployment 7 Examples Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given C Request authentication exchange S Empty Challenge C n a someuser S Send reply context token as is C Empty message S Outcome of authentication exchange Example 2 a one and one half round trip GSS API context token exchange no channel binding C Request authentication exchange S Empty Challenge C n S Send reply context token as is C Send reply context token as is S Outcome of authentication exchange Josefsson Expires September 4 2014 Page 13 Internet Draft SASL GS2 March 2014 Example 3 a two round trip GSS API context token exchange no channel binding no standard token header C Request authentication exchange S Empty Challenge C F n S Send reply context token as is C Send reply context token as is S Send reply context token as is C Empty message S Outcome of authentication exchange Example 4 using channel binding optional authzid given C Request authentication exchange S Empty Challenge C p tls unique a someuser S Send reply context token as is Example 5 using channel binding C Request authentication exchange S Empty Challenge C p tls unique S Send reply context token as is Example 6 using non standard channel binding requires out of band negotiation C Request authentication exchange S Empty Challenge C p tls server end point S Send reply context token as is Josefsson Expires September 4 2014 Page 14 Internet Draft SASL GS2 March 2014 Example 7 client supports channel bindings but server does not optional authzid given C Request authentication exchange S Empty Challenge C y a someuser S Send reply context token as is GSS API authentication is always initiated by the client The SASL framework allows either the client or the server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See Section 3 of RFC4422 8 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o If GSS Init Accept sec context returns anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o If the client s initial GS2 header does not match the ABNF o In particular if the initial character of the client message is anything except F p n or y o If the client s GS2 channel binding flag was y and the server supports channel bindings o If the client s GS2 channel binding flag was p and the server does not support the indicated channel binding o If the client requires use of channel binding and the server did not advertise support for channel binding o If 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 9 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the per message token ret flags from GSS Init sec context and GSS Accept sec context are irrelevant implementations SHOULD NOT set the per message req flags The mutual req flag MUST be set Clients MUST check that the Josefsson Expires September 4 2014 Page 15 Internet Draft SASL GS2 March 2014 corresponding ret flag is set when the context is fully established else authentication MUST fail Use or non use of deleg req flag and anon req flag is an implementation specific detail SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them SASL and GS2 implementors are encouraged to provide programming interfaces that provide a good mapping of GSS API naming options 10 Naming There is no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor principal names see RFC2743 Section 4 1 and clients will typically have username initiator principal names see RFC2743 Section 4 2 When a host based acceptor principal name is used service hostname service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server 11 GSS Inquire SASLname for mech Call We specify a new GSS API utility function to allow SASL implementations to more efficiently identify the GSS API mechanism to which a particular SASL mechanism name refers Josefsson Expires September 4 2014 Page 16 Internet Draft SASL GS2 March 2014 Inputs o desired mech OBJECT IDENTIFIER Outputs o major status INTEGER o minor status INTEGER o sasl mech name UTF 8 STRING SASL name for this mechanism caller must release with GSS Release buffer o mech name UTF 8 STRING name of this mechanism possibly localized caller must release with GSS Release buffer o mech description UTF 8 STRING possibly localized description of this mechanism caller must release with GSS Release buffer Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that a desired mech was unsupported by the GSS API implementation o GSS S FAILURE indicates that the operation failed for reasons unspecified at the GSS API level The GSS Inquire SASLname for mech call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in user friendly form The output variable sasl mech name will hold the IANA registered mechanism name for the GSS API mechanism or if none is registered a mechanism name computed from the OID as described in Section 3 1 of this document Josefsson Expires September 4 2014 Page 17 Internet Draft SASL GS2 March 2014 11 1 gss inquire saslname for mech The C binding for the GSS Inquire SASLname for mech call is as follows As mentioned in RFC2744 routines may return GSS S FAILURE indicating an implementation specific or mechanism specific error condition further details of which are reported via the minor status parameter Josefsson Expires September 4 2014 Page 18 Internet Draft SASL GS2 March 2014 OM uint32 gss inquire saslname for mech OM uint32 minor status const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description Purpose Output the SASL mechanism name of a GSS API mechanism It also returns a name and description of the mechanism in a user friendly form Parameters minor status Integer modify Mechanism specific status code desired mech OID read Identifies the GSS API mechanism to query sasl mech name buffer character string modify optional Buffer to receive SASL mechanism name The application must free storage associated with this name after use with a call to gss release buffer mech name buffer character string modify optional Buffer to receive human readable mechanism name The application must free storage associated with this name after use with a call to gss release buffer mech description buffer character string modify optional Buffer to receive description of mechanism The application must free storage associated with this name after use with a call to gss release buffer Function value GSS status code GSS S

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

  • Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family
    is not present the client MUST send a gs2 nonstd flag flag see below On the server side this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context except when the gs2 nonstd flag is sent A GS2 header MUST be prefixed to the resulting initial context token This header has the form gs2 header given below in ABNF RFC5234 Crocker D and P Overell Augmented BNF for Syntax Specifications ABNF January 2008 The figure below describes the permissible attributes their use and the format of their values All attribute names are single US ASCII letters and are case sensitive UTF8 1 safe x01 2B x2D 3C x3E 7F 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 safe UTF8 2 UTF8 3 UTF8 4 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname GS2 has to transport an authzid since the GSS API has no equivalent gs2 nonstd flag F F means the mechanism is not a standard GSS API mechanism in that the RFC 2743 Section 3 1 header was missing cb name 1 ALPHA DIGIT See RFC 5056 Section 7 gs2 cb flag p cb name n y GS2 channel binding CB flag p client supports and used CB n client does not support CB y client supports CB thinks the server does not gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid The GS2 header is gs2 header When the gs2 nonstd flag flag is present the client did not find remove a token header RFC2743 Linn J Generic Security Service Application Program Interface Version 2 Update 1 January 2000 Section 3 1 from the initial token returned by GSS Init sec context This signals to the server that it MUST NOT re add the data that is normally removed by the client The gs2 cb flag signals the channel binding mode One of p n or y is used A p means the client supports and used a channel binding and the name of the channel binding type is indicated An n means that the client does not support channel binding A y means the client supports channel binding but believes the server does not support it so it did not use a channel binding See the next section for more details The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 Yergeau F UTF 8 a transformation format of ISO 10646 November 2003 RFC3629 with three exceptions The NUL character is forbidden as required by section 3 4 1 of RFC4422 Melnikov A and K Zeilenga Simple Authentication and Security Layer SASL June 2006 The server MUST replace any comma in the string with 2C The server MUST replace any equals in the string with 3D Upon receipt of this value the server verifies its correctness according to the used SASL protocol profile Failed verification results in a failed authentication exchange TOC 5 Channel Bindings GS2 supports channel binding to external secure channels such as TLS Clients and servers may or may not support channel binding therefore the use of channel binding is negotiable However GS2 does not provide security layers therefore it is imperative that GS2 provide integrity protection for the negotiation of channel binding Use of channel binding is negotiated as follows Servers that support the use of channel binding SHOULD advertise both the non PLUS and PLUS variant of each GS2 mechanism name If the server cannot support channel binding it SHOULD advertise only the non PLUS variant If the server would never succeed in the authentication of the non PLUS variant due to policy reasons it MUST advertise only the PLUS variant If the client supports channel binding and the server does not appear to i e the client did not see the PLUS name advertised by the server then the client MUST NOT use an n gs2 cb flag Clients that support mechanism negotiation and channel binding MUST use a p gs2 cb flag when the server offers the PLUS variant of the desired GS2 mechanism If the client does not support channel binding then it MUST use an n gs2 cb flag Conversely if the client requires the use of channel binding then it MUST use a p gs2 cb flag Clients that do not support mechanism negotiation never use a y gs2 cb flag they use either p or n according to whether they require and support the use of channel binding or whether they do not respectively The client generates the chan bindings input parameter for GSS Init sec context as described below Upon receipt of the initial authentication message the server checks the gs2 cb flag in the GS2 header and constructs a chan bindings parameter for GSS Accept sec context as described below If the client channel binding flag was y and the server did advertise support for channel bindings by advertising the PLUS variant of the mechanism chosen by the client then the server MUST fail authentication If the client channel binding flag was p and the server does not support the indicated channel binding type then the server MUST fail authentication If the client used an n gs2 cb flag and the server requires the use of channel binding then the server MUST fail authentication FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION n no support N A If server disallows non channel bound authentication then fail y Yes not required No Authentication may succeed CB not used y Yes not required Yes Authentication must fail p Yes Yes Authentication may succeed with CB used p Yes No Authentication will fail N A Yes required No Client does not even try For more discussion of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 Williams N On the Use of Channel Bindings to Secure Channels November 2007 TOC 5 1 Content of GSS CHANNEL BINDINGS Structure The calls to GSS Init sec context and GSS Accept sec context take a chan bindings parameter The value is a GSS CHANNEL BINDINGS structure RFC5554 Williams N Clarifications and Extensions to the Generic Security Service Application Program Interface GSS API for the Use of Channel Bindings May 2009 The initiator address type and acceptor address type fields of the GSS CHANNEL BINDINGS structure MUST be set to 0 The initiator address and acceptor address fields MUST be the empty string The application data field MUST be set to the gs2 header excluding the initial gs2 nonstd flag part concatenated with when a gs2 cb flag of p is used the application s channel binding data TOC 5 2 Default Channel Binding A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows tls unique is the default channel binding type for any application that doesn t specify one Servers MUST implement the tls unique RFC5929 Altman J Williams N and L Zhu Channel Bindings for TLS July 2010 channel binding type if they implement any channel binding Clients SHOULD implement the tls unique channel binding type if they implement any channel binding Clients and servers SHOULD choose the highest layer innermost end to end TLS channel as the channel to which to bind Servers MUST choose the channel binding type indicated by the client or fail authentication if they don t support it TOC 6 When the mechanism does not support channel binding and or mutual authentication Some authentication mechanisms does not offer mutual authentication or is unable to provide channel bindings This is unfortunate and usually suggests that the authentication mechanism offers limited authentication functionality However there are situations when the lack of this functionality can be mitigated with other protection mechanisms leading to acceptable overall security Being able to define and use an authentication mechanism as a GSS API mechanism and then use that GSS API mechanism in the SASL environment using GS2 has advantages for example being able to re use existing generic GS2 implementations Further being able to express all mechanisms that can be expressed as a GSS API mechanisms as a SASL mechanism and vice versa provides design elegance and framework replacability Therefor this document relaxes the requirement that the GSS API mechanism support channel bindings and or mutual authentication Implementing and deploying applications that supports those mechanism require some consideration and this section discuss the relevant areas For the discussion it helps to understand what happens with the GS2 bridge when a GSS API mechanism does not offer channel bindings or mutual authentication When channel bindings is not supported by the underlying mechanism GS2 cannot protect its data essentially the channel binding flag and the SASL authorization identity This means that the security of the channel binding mode breaks down and that the other side cannot trust the SASL authorization identity When mutual authentication is not happening the client cannot know that it sends its data to the intended server It is acceptable to use these mechanisms with GS2 in some situations For example if the client uses TLS against a server and the client verify the server s certificate properly so that server authentication has occured then authenticating the client to the server using a weak GSS API mechanism will technically work The security properties will not be as good as they would have been if the underlying mechanism supported channel binding or mutual authentication however they become as good as possible This document relaxes the requirements on GSS API mechanism so that all GSS API mechanism can be expressed in GS2 For these mechanisms the gs2 cb flag value MUST always be n and the PLUS variant of the GS2 mechanism name MUST NOT be advertised or negotiated The SAML SASL bridge Wierenga K Lear E and S Josefsson A Simple Authentication and Security Layer SASL and GSS API Mechanism for the Security Assertion Markup Language SAML April 2012 RFC6595 and the SAML OpenID bridge Lear E Tschofenig H Mauldin H and S Josefsson A Simple Authentication and Security Layer SASL and Generic Security Service Application Program Interface GSS API Mechanism for OpenID May 2012 RFC6616 are two examples of documents that describe such bridges These documents did not meet the requirements of the original GS2 bridge but with the update in this document they are conformant Note that both documents had discussions describing this aspect and sufficient requirements for safe implementation and deployment TOC 7 Examples Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given C Request authentication exchange S Empty Challenge C n a someuser initial context token with standard header removed S Send reply context token as is C Empty message S Outcome of authentication exchange Example 2 a one and one half round trip GSS API context token exchange no channel binding C Request authentication exchange S Empty Challenge C n 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 Example 3 a two round trip GSS API context token exchange no channel binding no standard token header C Request authentication exchange S Empty Challenge C F n initial context token without standard header S Send reply context token as is C Send reply context token as is S Send reply context token as is C Empty message S Outcome of authentication exchange Example 4 using channel binding optional authzid given C Request authentication exchange S Empty Challenge C p tls unique a someuser 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 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 framework allows either the client or the server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See Section 3 of RFC4422 Melnikov A and K Zeilenga Simple Authentication and Security Layer SASL June 2006 TOC 8 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true If GSS Init Accept sec context returns anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE If the client s initial GS2 header does not match the ABNF In particular if the initial character of the client message is anything except F p n or y If the client s GS2 channel binding flag was y and the server supports channel bindings If the client s GS2 channel binding flag was p and the server does not support the indicated channel binding If the client requires use of channel binding and the server did not advertise support for channel binding If authorization of client principal i e src name in GSS Accept sec context to requested authzid failed If the client is not authorized to the requested authzid or an authzid could not be derived from the client s initiator principal name TOC 9 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the per message token ret flags from GSS Init sec context and GSS Accept sec context are irrelevant implementations SHOULD NOT set the per message req flags The mutual req flag MUST be set Clients MUST check that the corresponding ret flag is set when the context is fully established else authentication MUST fail Use or non use of deleg req flag and anon req flag is an implementation specific detail SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them SASL and GS2 implementors are encouraged to provide programming interfaces that provide a good mapping of GSS API naming options TOC 10 Naming There is no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor principal names see RFC2743 Linn J Generic Security Service Application Program Interface Version 2 Update 1 January 2000 Section 4 1 and clients will typically have username initiator principal names see RFC2743 Linn J Generic Security Service Application Program Interface Version 2 Update 1 January 2000 Section 4 2 When a host based acceptor principal name is used service hostname service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server TOC 11 GSS Inquire SASLname for mech Call We specify a new GSS API utility function to allow SASL implementations to more efficiently identify the GSS API mechanism to which a particular SASL mechanism name refers Inputs o desired mech OBJECT IDENTIFIER Outputs o major status INTEGER o minor status INTEGER o sasl mech name UTF 8 STRING SASL name for this mechanism caller must release with GSS Release buffer o mech name UTF 8 STRING name of this mechanism possibly localized caller must release with GSS Release buffer o mech description UTF 8 STRING possibly localized description of this mechanism caller must release with GSS Release buffer Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that a desired mech was unsupported by the GSS API implementation o GSS S FAILURE indicates that the operation failed for reasons unspecified at the GSS API level The GSS Inquire SASLname for mech call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in user friendly form The output variable sasl mech name will hold the IANA registered mechanism name for the GSS API mechanism or if none is registered a mechanism name computed from the OID as described in Section 3 1 of this document TOC 11 1 gss inquire saslname for mech The C binding for the GSS Inquire SASLname for mech call is as follows As mentioned in RFC2744 Wray J Generic Security Service API Version 2 C bindings January 2000 routines may return GSS S FAILURE indicating an implementation specific or mechanism specific error condition further details of which are reported via the minor status parameter OM uint32 gss inquire saslname for mech OM uint32 minor status const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description Purpose Output the SASL mechanism name of a GSS API mechanism It also returns a name and description of the mechanism in a user friendly form Parameters minor status Integer modify Mechanism specific status code desired mech OID read Identifies the GSS API mechanism to query sasl mech name buffer character string modify optional Buffer to receive SASL mechanism name The application must free storage associated with this name after use with a call to gss release buffer mech name buffer character string modify optional Buffer to receive human readable mechanism name The application must free storage associated with this name after use with a call to gss release buffer mech description

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

  • Diff: rfc5801.txt - draft-josefsson-kitten-gs2bis.txt
    use that GSS API mechanism in the SASL environment using GS2 has advantages for example being able to re use existing generic GS2 implementations Further being able to express all mechanisms that can be expressed as a GSS API mechanisms as a SASL mechanism and vice versa provides design elegance and framework replacability Therefor this document relaxes the requirement that the GSS API mechanism support channel bindings and or mutual authentication Implementing and deploying applications that supports those mechanism require some consideration and this section discuss the relevant areas For the discussion it helps to understand what happens with the GS2 bridge when a GSS API mechanism does not offer channel bindings or mutual authentication When channel bindings is not supported by the underlying mechanism GS2 cannot protect its data essentially the channel binding flag and the SASL authorization identity This means that the security of the channel binding mode breaks down and that the other side cannot trust the SASL authorization identity When mutual authentication is not happening the client cannot know that it sends its data to the intended server It is acceptable to use these mechanisms with GS2 in some situations For example if the client uses TLS against a server and the client verify the server s certificate properly so that server authentication has occured then authenticating the client to the server using a weak GSS API mechanism will technically work The security properties will not be as good as they would have been if the underlying mechanism supported channel binding or mutual authentication however they become as good as possible This document relaxes the requirements on GSS API mechanism so that all GSS API mechanism can be expressed in GS2 For these mechanisms the gs2 cb flag value MUST always be n and the PLUS variant of the GS2 mechanism name MUST NOT be advertised or negotiated The SAML SASL bridge RFC6595 and the SAML OpenID bridge RFC6616 are two examples of documents that describe such bridges These documents did not meet the requirements of the original GS2 bridge but with the update in this document they are conformant Note that both documents had discussions describing this aspect and sufficient requirements for safe implementation and deployment 7 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 n a 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 skipping to change at page 14 line 21 skipping to change at page 15 line 21 context token with standard header removed context token with standard 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 or the server to initiate framework allows either the client or the 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 8 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 If GSS Init Accept sec context returns anything other than o If GSS Init Accept sec context returns 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 If the client s initial GS2 header does not match the ABNF o In particular if the initial character of the client message is o In particular if the initial character of the client message is anything except F p n or y 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 bindings supports channel bindings o If the client s GS2 channel binding flag was p and the server o If the client s GS2 channel binding flag was p and the server does not support the indicated channel binding 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 If authorization of client principal i e src name in o If 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 9 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the per GS2 does not use any GSS API per message tokens Therefore the per message token ret flags from GSS Init sec context and message token ret flags from GSS Init sec context and GSS Accept sec context are irrelevant implementations SHOULD NOT GSS Accept sec context are irrelevant implementations SHOULD NOT set the per message req flags set the per message req flags The mutual req flag MUST be set Clients MUST check that the The mutual req flag MUST be set Clients MUST check that the corresponding ret flag is set when the context is fully established corresponding ret flag is set when the context is fully established else authentication MUST fail else authentication MUST fail Use or non use of deleg req flag and anon req flag is an Use or non use of deleg req flag and anon req flag is an implementation specific detail SASL and GS2 implementors are implementation specific detail SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them choose to delegate credentials and by which servers may receive them SASL and GS2 implementors are encouraged to provide programming SASL and GS2 implementors are encouraged to provide programming interfaces that provide a good mapping of GSS API naming options interfaces that provide a good mapping of GSS API naming options 9 Naming 10 Naming There is no requirement that any particular GSS API name types be There is 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 When a host based acceptor principal name is used Section 4 2 When a host based acceptor principal name is used service hostname service is the service name specified in the service hostname service is the service name specified in the protocol s profile and hostname is the fully qualified host name of protocol s profile and hostname is the fully qualified host name of the server the server 1 0 GSS Inquire SASLname for mech Call 1 1 GSS Inquire SASLname for mech Call We specify a new GSS API utility function to allow SASL We specify a new GSS API utility function to allow SASL implementations to more efficiently identify the GSS API mechanism to implementations to more efficiently identify the GSS API mechanism to which a particular SASL mechanism name refers which a particular SASL mechanism name refers Inputs Inputs o desired mech OBJECT IDENTIFIER o desired mech OBJECT IDENTIFIER Outputs Outputs skipping to change at page 16 line 32 skipping to change at page 18 line 5 The GSS Inquire SASLname for mech call is used to get the SASL The GSS Inquire SASLname for mech call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in user friendly form and description of the mechanism in user friendly form The output variable sasl mech name will hold the IANA registered The output variable sasl mech name will hold the IANA registered mechanism name for the GSS API mechanism or if none is mechanism name for the GSS API mechanism or if none is registered a mechanism name computed from the OID as described registered a mechanism name computed from the OID as described in Section 3 1 of this document in Section 3 1 of this document 1 0 1 gss inquire saslname for mech 1 1 1 gss inquire saslname for mech The C binding for the GSS Inquire SASLname for mech call is as The C binding for the GSS Inquire SASLname for mech call is as follows follows As mentioned in RFC2744 routines may return GSS S FAILURE As mentioned in RFC2744 routines may return GSS S FAILURE indicating an implementation specific or mechanism specific error indicating an implementation specific or mechanism specific error condition further details of which are reported via the minor status condition further details of which are reported via the minor status parameter parameter OM uint32 gss inquire saslname for mech OM uint32 gss inquire saslname for mech skipping to change at page 18 line 5 skipping to change at page 20 line 5 The application must free storage associated The application must free storage associated with this name after use with a call to with this name after use with a call to gss release buffer gss release buffer Function value GSS status code Function value GSS status code GSS S COMPLETE Successful completion GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported GSS S BAD MECH The desired mech OID is unsupported 1 1 GSS Inquire mech for SASLname Call 1 2 GSS Inquire mech for SASLname Call To allow SASL clients to more efficiently identify to which GSS API To allow SASL clients to more efficiently identify to which GSS API mechanism a particular SASL mechanism name refers we specify a new mechanism a particular SASL mechanism name refers we specify a new GSS API utility function for this purpose GSS API utility function for this purpose Inputs Inputs o sasl mech name UTF 8 STRING SASL name of mechanism o sasl mech name UTF 8 STRING SASL name of mechanism Outputs Outputs skipping to change at page 19 line 5 skipping to change at page 21 line 5 o GSS S BAD MECH indicates that no supported GSS API mechanism o GSS S BAD MECH indicates that no supported GSS API mechanism had the indicated sasl mech name had the indicated sasl mech name o GSS S FAILURE indicates that the operation failed for reasons o GSS S FAILURE indicates that the operation failed for reasons unspecified at the GSS API level unspecified at the GSS API level The GSS Inquire mech for SASLname call is used to get the GSS API The GSS Inquire mech for SASLname call is used to get the GSS API mechanism OID associated with a SASL mechanism name mechanism OID associated with a SASL mechanism name 1 1 1 gss inquire mech for saslname 1 2 1 gss inquire mech for saslname The C binding for the GSS Inquire mech for SASLname call is as The C binding for the GSS Inquire mech for SASLname call is as follows follows As mentioned in RFC2744 routines may return GSS S FAILURE As mentioned in RFC2744 routines may return GSS S FAILURE indicating an implementation specific or mechanism specific error indicating an implementation specific or mechanism specific error condition further details of which are reported via the minor status condition further details of which are reported via the minor status parameter parameter OM uint32 gss inquire mech for saslname OM uint32 gss inquire mech for saslname skipping to change at page 20 line 5 skipping to change at page 21 line 48 In particular the application should not attempt In particular the application should not attempt to free it Specify NULL if not required to free it Specify NULL if not required Function value GSS status code Function value GSS status code GSS S COMPLETE Successful completion GSS S COMPLETE Successful completion GSS S BAD MECH There is no GSS API mechanism known GSS S BAD MECH There is no GSS API mechanism known as sasl mech name as sasl mech name 1 2 Security Layers 1 3 Security Layers GS2 does not support SASL security layers Applications that need GS2 does not support SASL security layers Applications that need integrity or confidentiality protection can use either channel integrity or confidentiality protection can use either channel binding to a secure external channel or another SASL mechanism that binding to a secure external channel or another SASL mechanism that does provide security layers does provide security layers 1 3 Interoperability with the SASL GSSAPI Mechanism 1 4 Interoperability with the SASL GSSAPI Mechanism The Kerberos V5 GSS API RFC1964 mechanism is currently used in SASL The Kerberos V5 GSS API RFC1964 mechanism is currently used in SASL under the name GSSAPI see RFC4752 The Kerberos V5 mechanism may under the name GSSAPI see RFC4752 The Kerberos V5 mechanism may also be used with the GS2 family This causes an interoperability also be used with the GS2 family This causes an interoperability problem which is discussed and resolved below problem which is discussed and resolved below 1 3 1 The Interoperability Problem 1 4 1 The Interoperability Problem The SASL GSSAPI mechanism is not wire compatible with the Kerberos The SASL GSSAPI mechanism is not wire compatible with the Kerberos V GSS API mechanism used as a SASL GS2 mechanism V GSS API mechanism used as a SASL GS2 mechanism 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 mechanism negotiation will fail GS2 family the mechanism negotiation will fail 1 3 2 Resolving the Problem 1 4 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 SASL GSSAPI mechanism lacks support for channel bindings which The SASL GSSAPI mechanism lacks support for channel bindings which means that using an external secure channel may not be sufficient means that using an external secure channel may not be sufficient protection against active attackers see RFC5056 and MITM protection against active attackers see RFC5056 and MITM 1 3 3 Additional Recommendations 1 4 3 Additional Recommendations If the application requires SASL security layers then it MUST use If the application requires SASL security layers then it MUST use the SASL GSSAPI mechanism RFC4752 instead of GS2 KRB5 or GS2 the SASL GSSAPI mechanism RFC4752 instead of GS2 KRB5 or GS2 KRB5 PLUS KRB5 PLUS If the application can use channel binding to an external channel If the application can use channel binding to an external channel then it is RECOMMENDED that it select Kerberos V5 through the GS2 then it is RECOMMENDED that it select Kerberos V5 through the GS2 mechanism rather than the GSSAPI mechanism mechanism rather than the GSSAPI mechanism 1 4 GSS API Mechanisms That Negotiate Other Mechanisms 1 5 GSS API Mechanisms That Negotiate Other Mechanisms A GSS API mechanism that negotiates other mechanisms will interact A GSS API mechanism that negotiates other mechanisms will interact badly with the SASL mechanism negotiation There are two problems badly with the SASL mechanism negotiation There are two problems The first is an interoperability problem and the second is a security The first is an interoperability problem and the second is a security concern The problems are described and resolved below concern The problems are described and resolved below 1 4 1 The Interoperability Problem 1 5 1 The Interoperability Problem If a client implements GSS API mechanism X potentially negotiated If a client implements GSS API mechanism X potentially negotiated through a GSS API mechanism Y and the server also implements GSS API through a GSS API mechanism Y and the server also implements GSS API mechanism X negotiated through a GSS API mechanism Z the mechanism

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


  • in Base32 RFC4648 Thus the SASL mechanism name for the Kerberos V5 GSS API mechanism would be GS2 QLJHGJLWNPL and because this mechanism Josefsson Williams Expires January 14 2011 Page 7 Internet Draft SASL GS2 July 2010 supports channel binding GS2 QLJHGJLWNPL PLUS Instead the next section assigns the Kerberos V5 mechanism a non hash derived mechanism name 3 4 Grandfathered Mechanism Names Some older GSS API mechanisms were not specified with a SASL GS2 mechanism name Using a shorter name can be useful nonetheless We specify the names GS2 KRB5 and GS2 KRB5 PLUS for the Kerberos V5 mechanism to be used as if the original specification documented it see Section 15 4 SASL Authentication Exchange Message Format During the SASL authentication exchange for GS2 a number of messages following the following format are sent between the client and server On success this number is the same as the number of context tokens that the GSS API mechanism would normally require in order to establish a security context On failures the exchange can be terminated early by any party When using a GS2 mechanism the SASL client is always a GSS API initiator and the SASL server is always a GSS API acceptor The client calls GSS Init sec context and the server calls GSS Accept sec context All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for the initial security context token The client and server MAY send GSS API error tokens tokens output by GSS Init sec context or GSS Accept sec context when the major status code is other than GSS S COMPLETE or GSS S CONTINUE NEEDED As this indicates an error condition after sending the token the sending side should fail the authentication The initial security context token is modified as follows o The initial context token header see Section 3 1 of RFC2743 MUST be removed if present If the header is not present the client MUST send a gs2 nonstd flag flag see below On the server side this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context except when the gs2 nonstd flag is sent o A GS2 header MUST be prefixed to the resulting initial context token This header has the form gs2 header given below in ABNF RFC5234 Josefsson Williams Expires January 14 2011 Page 8 Internet Draft SASL GS2 July 2010 The figure below describes the permissible attributes their use and the format of their values All attribute names are single US ASCII letters and are case sensitive UTF8 1 safe x01 2B x2D 3C x3E 7F As UTF8 1 in RFC 3629 except NUL and UTF8 2 UTF8 3 UTF8 4 UTF8 char safe UTF8 1 safe UTF8 2 UTF8 3 UTF8 4 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname GS2 has to transport an authzid since the GSS API has no equivalent gs2 nonstd flag F F means the mechanism is not a standard GSS API mechanism in that the RFC 2743 Section 3 1 header was missing cb name 1 ALPHA DIGIT See RFC 5056 Section 7 gs2 cb flag p cb name n y GS2 channel binding CB flag p client supports and used CB n client does not support CB y client supports CB thinks the server does not gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid The GS2 header is gs2 header When the gs2 nonstd flag flag is present the client did not find remove a token header RFC2743 Section 3 1 from the initial token returned by GSS Init sec context This signals to the server that it MUST NOT re add the data that is normally removed by the client The gs2 cb flag signals the channel binding mode One of p n or y is used A p means the client supports and used a channel binding and the name of the channel binding type is indicated An n means that the client does not support channel binding A y means the client supports channel binding but believes the server does not support it so it did not use a channel binding See the next section for more details The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 RFC3629 with three exceptions Josefsson Williams Expires January 14 2011 Page 9 Internet Draft SASL GS2 July 2010 o The NUL character is forbidden as required by section 3 4 1 of RFC4422 o The server MUST replace any comma in the string with 2C o The server MUST replace any equals in the string with 3D Upon receipt of this value the server verifies its correctness according to the used SASL protocol profile Failed verification results in a failed authentication exchange 5 Channel Bindings GS2 supports channel binding to external secure channels such as TLS Clients and servers may or may not support channel binding therefore the use of channel binding is negotiable However GS2 does not provide security layers therefore it is imperative that GS2 provide integrity protection for the negotiation of channel binding Use of channel binding is negotiated as follows o Servers that support the use of channel binding SHOULD advertise both the non PLUS and PLUS variant of each GS2 mechanism name If the server cannot support channel binding it SHOULD advertise only the non PLUS variant If the server would never succeed in the authentication of the non PLUS variant due to policy reasons it MUST advertise only the PLUS variant o If the client supports channel binding and the server does not appear to i e the client did not see the PLUS name advertised by the server then the client MUST NOT use an n gs2 cb flag o Clients that support mechanism negotiation and channel binding MUST use a p gs2 cb flag when the server offers the PLUS variant of the desired GS2 mechanism o If the client does not support channel binding then it MUST use an n gs2 cb flag Conversely if the client requires the use of channel binding then it MUST use a p gs2 cb flag Clients that do not support mechanism negotiation never use a y gs2 cb flag they use either p or n according to whether they require and support the use of channel binding or whether they do not respectively o The client generates the chan bindings input parameter for GSS Init sec context as described below o Upon receipt of the initial authentication message the server checks the gs2 cb flag in the GS2 header and constructs a chan bindings parameter for GSS Accept sec context as described below If the client channel binding flag was y and the server did advertise support for channel bindings by advertising the PLUS variant of the mechanism chosen by the client then the server MUST fail authentication If the client channel binding flag was p and the server does not support the indicated channel Josefsson Williams Expires January 14 2011 Page 10 Internet Draft SASL GS2 July 2010 binding type then the server MUST fail authentication o If the client used an n gs2 cb flag and the server requires the use of channel binding then the server MUST fail authentication FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION n no support N A If server disallows non channel bound authentication then fail y Yes not required No Authentication may succeed CB not used y Yes not required Yes Authentication must fail p Yes Yes Authentication may succeed with CB used p Yes No Authentication will fail N A Yes required No Client does not even try For more discussion of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 5 1 Content of GSS CHANNEL BINDINGS Structure The calls to GSS Init sec context and GSS Accept sec context take a chan bindings parameter The value is a GSS CHANNEL BINDINGS structure RFC5554 The initiator address type and acceptor address type fields of the GSS CHANNEL BINDINGS structure MUST be set to 0 The initiator address and acceptor address fields MUST be the empty string The application data field MUST be set to the gs2 header excluding the initial gs2 nonstd flag part concatenated with when a gs2 cb flag of p is used the application s channel binding data 5 2 Default Channel Binding A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows tls unique is the default channel binding type for any application Josefsson Williams Expires January 14 2011 Page 11 Internet Draft SASL GS2 July 2010 that doesn t specify one Servers MUST implement the tls unique RFC5929 channel binding type if they implement any channel binding Clients SHOULD implement the tls unique channel binding type if they implement any channel binding Clients and servers SHOULD choose the highest layer innermost end to end TLS channel as the channel to which to bind Servers MUST choose the channel binding type indicated by the client or fail authentication if they don t support it 6 Examples Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given C Request authentication exchange S Empty Challenge C n a someuser S Send reply context token as is C Empty message S Outcome of authentication exchange Example 2 a one and one half round trip GSS API context token exchange no channel binding C Request authentication exchange S Empty Challenge C n S Send reply context token as is C Send reply context token as is S Outcome of authentication exchange Josefsson Williams Expires January 14 2011 Page 12 Internet Draft SASL GS2 July 2010 Example 3 a two round trip GSS API context token exchange no channel binding no standard token header C Request authentication exchange S Empty Challenge C F n S Send reply context token as is C Send reply context token as is S Send reply context token as is C Empty message S Outcome of authentication exchange Example 4 using channel binding optional authzid given C Request authentication exchange S Empty Challenge C p tls unique a someuser S Send reply context token as is Example 5 using channel binding C Request authentication exchange S Empty Challenge C p tls unique S Send reply context token as is Example 6 using non standard channel binding requires out of band negotiation C Request authentication exchange S Empty Challenge C p tls server end point S Send reply context token as is Josefsson Williams Expires January 14 2011 Page 13 Internet Draft SASL GS2 July 2010 Example 7 client supports channel bindings but server does not optional authzid given C Request authentication exchange S Empty Challenge C y a someuser S Send reply context token as is GSS API authentication is always initiated by the client The SASL framework allows either the client or the server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See Section 3 of RFC4422 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o If GSS Init Accept sec context returns anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o If the client s initial GS2 header does not match the ABNF o In particular if the initial character of the client message is anything except F p n or y o If the client s GS2 channel binding flag was y and the server supports channel bindings o If the client s GS2 channel binding flag was p and the server does not support the indicated channel binding o If the client requires use of channel binding and the server did not advertise support for channel binding o If authorization of client principal i e src name in GSS Accept sec context to requested authzid failed o If the client is not authorized to the requested authzid or an authzid could not be derived from the client s initiator principal name 8 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the per message token ret flags from GSS Init sec context and GSS Accept sec context are irrelevant implementations SHOULD NOT set the per message req flags The mutual req flag MUST be set Clients MUST check that the Josefsson Williams Expires January 14 2011 Page 14 Internet Draft SASL GS2 July 2010 corresponding ret flag is set when the context is fully established else authentication MUST fail Use or non use of deleg req flag and anon req flag is an implementation specific detail SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them SASL and GS2 implementors are encouraged to provide programming interfaces that provide a good mapping of GSS API naming options 9 Naming There is no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor principal names see RFC2743 Section 4 1 and clients will typically have username initiator principal names see RFC2743 Section 4 2 When a host based acceptor principal name is used service hostname service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server 10 GSS Inquire SASLname for mech Call We specify a new GSS API utility function to allow SASL implementations to more efficiently identify the GSS API mechanism to which a particular SASL mechanism name refers Josefsson Williams Expires January 14 2011 Page 15 Internet Draft SASL GS2 July 2010 Inputs o desired mech OBJECT IDENTIFIER Outputs o major status INTEGER o minor status INTEGER o sasl mech name UTF 8 STRING SASL name for this mechanism caller must release with GSS Release buffer o mech name UTF 8 STRING name of this mechanism possibly localized caller must release with GSS Release buffer o mech description UTF 8 STRING possibly localized description of this mechanism caller must release with GSS Release buffer Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that a desired mech was unsupported by the GSS API implementation o GSS S FAILURE indicates that the operation failed for reasons unspecified at the GSS API level The GSS Inquire SASLname for mech call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in user friendly form The output variable sasl mech name will hold the IANA registered mechanism name for the GSS API mechanism or if none is registered a mechanism name computed from the OID as described in Section 3 1 of this document Josefsson Williams Expires January 14 2011 Page 16 Internet Draft SASL GS2 July 2010 10 1 gss inquire saslname for mech The C binding for the GSS Inquire SASLname for mech call is as follows As mentioned in RFC2744 routines may return GSS S FAILURE indicating an implementation specific or mechanism specific error condition further details of which are reported via the minor status parameter Josefsson Williams Expires January 14 2011 Page 17 Internet Draft SASL GS2 July 2010 OM uint32 gss inquire saslname for mech OM uint32 minor status const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description Purpose Output the SASL mechanism name of a GSS API mechanism It also returns a name and description of the mechanism in a user friendly form Parameters minor status Integer modify Mechanism specific status code desired mech OID read Identifies the GSS API mechanism to query sasl mech name buffer character string modify optional Buffer to receive SASL mechanism name The application must free storage associated with this name after use with a call to gss release buffer mech name buffer character string modify optional Buffer to receive human readable mechanism name The application must free storage associated with this name after use with a call to gss release buffer mech description buffer character string modify optional Buffer to receive description of mechanism The application must free storage associated with this name after use with a call to gss release buffer Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported Josefsson Williams Expires January 14 2011 Page 18 Internet Draft SASL GS2 July 2010 11 GSS Inquire mech for SASLname Call To allow SASL clients to more efficiently identify to which GSS API mechanism a particular SASL mechanism name refers we specify a new GSS API utility function for this purpose Inputs o sasl mech name UTF 8 STRING SASL name of mechanism Outputs o major status INTEGER o minor status INTEGER o mech type OBJECT IDENTIFIER must be explicit mechanism and not default specifier Caller should treat as read only and should not attempt to release Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that no supported GSS API mechanism had the indicated sasl mech name o GSS S FAILURE indicates that the operation failed for reasons unspecified at the GSS API level The GSS Inquire mech for SASLname call is used to get the GSS API mechanism OID associated with a SASL mechanism name Josefsson Williams Expires January 14 2011 Page 19 Internet Draft SASL GS2 July 2010 11 1 gss inquire mech for saslname The C binding for the GSS Inquire mech for SASLname

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

  • Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family
    Using a shorter name can be useful nonetheless We specify the names GS2 KRB5 and GS2 KRB5 PLUS for the Kerberos V5 mechanism to be used as if the original specification documented it see Section 15 IANA Considerations TOC 4 SASL Authentication Exchange Message Format During the SASL authentication exchange for GS2 a number of messages following the following format are sent between the client and server On success this number is the same as the number of context tokens that the GSS API mechanism would normally require in order to establish a security context On failures the exchange can be terminated early by any party When using a GS2 mechanism the SASL client is always a GSS API initiator and the SASL server is always a GSS API acceptor The client calls GSS Init sec context and the server calls GSS Accept sec context All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS API mechanism except for the initial security context token The client and server MAY send GSS API error tokens tokens output by GSS Init sec context or GSS Accept sec context when the major status code is other than GSS S COMPLETE or GSS S CONTINUE NEEDED As this indicates an error condition after sending the token the sending side should fail the authentication The initial security context token is modified as follows The initial context token header see Section 3 1 of RFC2743 Linn J Generic Security Service Application Program Interface Version 2 Update 1 January 2000 MUST be removed if present If the header is not present the client MUST send a gs2 nonstd flag flag see below On the server side this header MUST be recomputed and restored prior to passing the token to GSS Accept sec context except when the gs2 nonstd flag is sent A GS2 header MUST be prefixed to the resulting initial context token This header has the form gs2 header given below in ABNF RFC5234 Crocker D and P Overell Augmented BNF for Syntax Specifications ABNF January 2008 The figure below describes the permissible attributes their use and the format of their values All attribute names are single US ASCII letters and are case sensitive UTF8 1 safe x01 2B x2D 3C x3E 7F 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 safe UTF8 2 UTF8 3 UTF8 4 saslname 1 UTF8 char safe 2C 3D gs2 authzid a saslname GS2 has to transport an authzid since the GSS API has no equivalent gs2 nonstd flag F F means the mechanism is not a standard GSS API mechanism in that the RFC 2743 Section 3 1 header was missing cb name 1 ALPHA DIGIT See RFC 5056 Section 7 gs2 cb flag p cb name n y GS2 channel binding CB flag p client supports and used CB n client does not support CB y client supports CB thinks the server does not gs2 header gs2 nonstd flag gs2 cb flag gs2 authzid The GS2 header is gs2 header When the gs2 nonstd flag flag is present the client did not find remove a token header RFC2743 Linn J Generic Security Service Application Program Interface Version 2 Update 1 January 2000 Section 3 1 from the initial token returned by GSS Init sec context This signals to the server that it MUST NOT re add the data that is normally removed by the client The gs2 cb flag signals the channel binding mode One of p n or y is used A p means the client supports and used a channel binding and the name of the channel binding type is indicated An n means that the client does not support channel binding A y means the client supports channel binding but believes the server does not support it so it did not use a channel binding See the next section for more details The gs2 authzid holds the SASL authorization identity It is encoded using UTF 8 Yergeau F UTF 8 a transformation format of ISO 10646 November 2003 RFC3629 with three exceptions The NUL character is forbidden as required by section 3 4 1 of RFC4422 Melnikov A and K Zeilenga Simple Authentication and Security Layer SASL June 2006 The server MUST replace any comma in the string with 2C The server MUST replace any equals in the string with 3D Upon receipt of this value the server verifies its correctness according to the used SASL protocol profile Failed verification results in a failed authentication exchange TOC 5 Channel Bindings GS2 supports channel binding to external secure channels such as TLS Clients and servers may or may not support channel binding therefore the use of channel binding is negotiable However GS2 does not provide security layers therefore it is imperative that GS2 provide integrity protection for the negotiation of channel binding Use of channel binding is negotiated as follows Servers that support the use of channel binding SHOULD advertise both the non PLUS and PLUS variant of each GS2 mechanism name If the server cannot support channel binding it SHOULD advertise only the non PLUS variant If the server would never succeed in the authentication of the non PLUS variant due to policy reasons it MUST advertise only the PLUS variant If the client supports channel binding and the server does not appear to i e the client did not see the PLUS name advertised by the server then the client MUST NOT use an n gs2 cb flag Clients that support mechanism negotiation and channel binding MUST use a p gs2 cb flag when the server offers the PLUS variant of the desired GS2 mechanism If the client does not support channel binding then it MUST use an n gs2 cb flag Conversely if the client requires the use of channel binding then it MUST use a p gs2 cb flag Clients that do not support mechanism negotiation never use a y gs2 cb flag they use either p or n according to whether they require and support the use of channel binding or whether they do not respectively The client generates the chan bindings input parameter for GSS Init sec context as described below Upon receipt of the initial authentication message the server checks the gs2 cb flag in the GS2 header and constructs a chan bindings parameter for GSS Accept sec context as described below If the client channel binding flag was y and the server did advertise support for channel bindings by advertising the PLUS variant of the mechanism chosen by the client then the server MUST fail authentication If the client channel binding flag was p and the server does not support the indicated channel binding type then the server MUST fail authentication If the client used an n gs2 cb flag and the server requires the use of channel binding then the server MUST fail authentication FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION n no support N A If server disallows non channel bound authentication then fail y Yes not required No Authentication may succeed CB not used y Yes not required Yes Authentication must fail p Yes Yes Authentication may succeed with CB used p Yes No Authentication will fail N A Yes required No Client does not even try For more discussion of channel bindings and the syntax of the channel binding data for various security protocols see RFC5056 Williams N On the Use of Channel Bindings to Secure Channels November 2007 TOC 5 1 Content of GSS CHANNEL BINDINGS Structure The calls to GSS Init sec context and GSS Accept sec context take a chan bindings parameter The value is a GSS CHANNEL BINDINGS structure RFC5554 Williams N Clarifications and Extensions to the Generic Security Service Application Program Interface GSS API for the Use of Channel Bindings May 2009 The initiator address type and acceptor address type fields of the GSS CHANNEL BINDINGS structure MUST be set to 0 The initiator address and acceptor address fields MUST be the empty string The application data field MUST be set to the gs2 header excluding the initial gs2 nonstd flag part concatenated with when a gs2 cb flag of p is used the application s channel binding data TOC 5 2 Default Channel Binding A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows tls unique is the default channel binding type for any application that doesn t specify one Servers MUST implement the tls unique RFC5929 Altman J Williams N and L Zhu Channel Bindings for TLS July 2010 channel binding type if they implement any channel binding Clients SHOULD implement the tls unique channel binding type if they implement any channel binding Clients and servers SHOULD choose the highest layer innermost end to end TLS channel as the channel to which to bind Servers MUST choose the channel binding type indicated by the client or fail authentication if they don t support it TOC 6 Examples Example 1 a one round trip GSS API context token exchange no channel binding optional authzid given C Request authentication exchange S Empty Challenge C n a someuser initial context token with standard header removed S Send reply context token as is C Empty message S Outcome of authentication exchange Example 2 a one and one half round trip GSS API context token exchange no channel binding C Request authentication exchange S Empty Challenge C n 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 Example 3 a two round trip GSS API context token exchange no channel binding no standard token header C Request authentication exchange S Empty Challenge C F n initial context token without standard header S Send reply context token as is C Send reply context token as is S Send reply context token as is C Empty message S Outcome of authentication exchange Example 4 using channel binding optional authzid given C Request authentication exchange S Empty Challenge C p tls unique a someuser 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 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 framework allows either the client or the server to initiate authentication In GS2 the server will send an initial empty challenge zero byte string if it has not yet received a token from the client See Section 3 of RFC4422 Melnikov A and K Zeilenga Simple Authentication and Security Layer SASL June 2006 TOC 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true If GSS Init Accept sec context returns anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE If the client s initial GS2 header does not match the ABNF In particular if the initial character of the client message is anything except F p n or y If the client s GS2 channel binding flag was y and the server supports channel bindings If the client s GS2 channel binding flag was p and the server does not support the indicated channel binding If the client requires use of channel binding and the server did not advertise support for channel binding If authorization of client principal i e src name in GSS Accept sec context to requested authzid failed If the client is not authorized to the requested authzid or an authzid could not be derived from the client s initiator principal name TOC 8 GSS API Parameters GS2 does not use any GSS API per message tokens Therefore the per message token ret flags from GSS Init sec context and GSS Accept sec context are irrelevant implementations SHOULD NOT set the per message req flags The mutual req flag MUST be set Clients MUST check that the corresponding ret flag is set when the context is fully established else authentication MUST fail Use or non use of deleg req flag and anon req flag is an implementation specific detail SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them SASL and GS2 implementors are encouraged to provide programming interfaces that provide a good mapping of GSS API naming options TOC 9 Naming There is no requirement that any particular GSS API name types be used However typically SASL servers will have host based acceptor principal names see RFC2743 Linn J Generic Security Service Application Program Interface Version 2 Update 1 January 2000 Section 4 1 and clients will typically have username initiator principal names see RFC2743 Linn J Generic Security Service Application Program Interface Version 2 Update 1 January 2000 Section 4 2 When a host based acceptor principal name is used service hostname service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server TOC 10 GSS Inquire SASLname for mech Call We specify a new GSS API utility function to allow SASL implementations to more efficiently identify the GSS API mechanism to which a particular SASL mechanism name refers Inputs o desired mech OBJECT IDENTIFIER Outputs o major status INTEGER o minor status INTEGER o sasl mech name UTF 8 STRING SASL name for this mechanism caller must release with GSS Release buffer o mech name UTF 8 STRING name of this mechanism possibly localized caller must release with GSS Release buffer o mech description UTF 8 STRING possibly localized description of this mechanism caller must release with GSS Release buffer Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that a desired mech was unsupported by the GSS API implementation o GSS S FAILURE indicates that the operation failed for reasons unspecified at the GSS API level The GSS Inquire SASLname for mech call is used to get the SASL mechanism name for a GSS API mechanism It also returns a name and description of the mechanism in user friendly form The output variable sasl mech name will hold the IANA registered mechanism name for the GSS API mechanism or if none is registered a mechanism name computed from the OID as described in Section 3 1 of this document TOC 10 1 gss inquire saslname for mech The C binding for the GSS Inquire SASLname for mech call is as follows As mentioned in RFC2744 Wray J Generic Security Service API Version 2 C bindings January 2000 routines may return GSS S FAILURE indicating an implementation specific or mechanism specific error condition further details of which are reported via the minor status parameter OM uint32 gss inquire saslname for mech OM uint32 minor status const gss OID desired mech gss buffer t sasl mech name gss buffer t mech name gss buffer t mech description Purpose Output the SASL mechanism name of a GSS API mechanism It also returns a name and description of the mechanism in a user friendly form Parameters minor status Integer modify Mechanism specific status code desired mech OID read Identifies the GSS API mechanism to query sasl mech name buffer character string modify optional Buffer to receive SASL mechanism name The application must free storage associated with this name after use with a call to gss release buffer mech name buffer character string modify optional Buffer to receive human readable mechanism name The application must free storage associated with this name after use with a call to gss release buffer mech description buffer character string modify optional Buffer to receive description of mechanism The application must free storage associated with this name after use with a call to gss release buffer Function value GSS status code GSS S COMPLETE Successful completion GSS S BAD MECH The desired mech OID is unsupported TOC 11 GSS Inquire mech for SASLname Call To allow SASL clients to more efficiently identify to which GSS API mechanism a particular SASL mechanism name refers we specify a new GSS API utility function for this purpose Inputs o sasl mech name UTF 8 STRING SASL name of mechanism Outputs o major status INTEGER o minor status INTEGER o mech type OBJECT IDENTIFIER must be explicit mechanism and not default specifier Caller should treat as read only and should not attempt to release Return major status codes o GSS S COMPLETE indicates successful completion and that output parameters holds correct information o GSS S BAD MECH indicates that no supported GSS API mechanism had the indicated sasl mech name o GSS S FAILURE indicates that the operation failed for reasons unspecified at the GSS API level The GSS Inquire mech for SASLname call is used to get the GSS API mechanism OID associated with a SASL mechanism name TOC 11 1 gss inquire mech for saslname The C binding for the GSS Inquire mech for SASLname call is as follows As mentioned in RFC2744 Wray J Generic Security Service API

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



  •