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-06.txt - draft-ietf-sasl-gs2-07.txt
    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 36 skipping to change at page 26 line 36 when it ideally should have used mechanism Y For this reason the when it ideally should have used mechanism Y For this reason the use of GSS API mechanisms that negotiate other mechanisms are use of GSS API mechanisms that negotiate other mechanisms are disallowed under GS2 disallowed under GS2 12 3 Resolving the problems 12 3 Resolving the problems GSS API mechanisms that negotiate other mechanisms MUST NOT be used GSS API mechanisms that negotiate other mechanisms MUST NOT be used with the GS2 SASL mechanism This specifically exclude negotiating with the GS2 SASL mechanism This specifically exclude negotiating SPNEGO 11 under GS2 SPNEGO 11 under GS2 The GSS C MA MECH NEGO attribute of GSS Inquire attrs for mech 1 6 The GSS C MA MECH NEGO attribute of GSS Inquire attrs for mech 1 7 can be used to identify such mechanisms can be used to identify such mechanisms 13 IANA Considerations 13 IANA Considerations The IANA is advised that SASL mechanism names starting with GS2 The IANA is advised that SASL mechanism names starting with GS2 are reserved for SASL mechanisms which conform to this document The are reserved for SASL mechanisms which conform to this document The IANA is directed to place a statement to that effect in the sasl IANA is directed to place a statement to that effect in the sasl mechanisms registry mechanisms registry Subject Registration of SASL mechanism GS2 Subject Registration of SASL mechanism GS2 skipping to change at page 28 line 7 skipping to change at page 28 line 7 Security considerations RFC THIS DOC Security considerations RFC THIS DOC Published specification RFC THIS DOC Published specification RFC THIS DOC Person email address to contact for further information Person email address to contact for further information Simon Josefsson simon josefsson org Simon Josefsson simon josefsson org Intended usage COMMON Intended usage COMMON Owner Change controller iesg ietf org Owner Change controller iesg ietf org Note Compare with the GSSAPI and GSS SPNEGO mechanisms Note Compare with the GSSAPI and GSS SPNEGO mechanisms 14 Security Considerations 14 Security Considerations Security issues are discussed throughout this memo The security provided by GS2 depends on the security provided by the The security provided by GS2 depends on the security provided by the GSS API mechanism If the mechanism do not provide integrity GSS API mechanism If the mechanism do not provide integrity protection the authorization identity can be replaced by a man in protection the authorization identity can be replaced by a man in the middle and channel bindings and security layers cannot be the middle and channel bindings and security layers cannot be negotiated Therefor it is generally recommended against using any negotiated Therefor it is generally recommended against using any GSS API mechanism widely on the Internet that do not support GSS API mechanism widely on the Internet that do not support integrity integrity Because the negotiation of a GSS API mechanism may be done in the Because the negotiation of a particular GSS API mechanism may be done clear it is important for the GSS API mechanisms to be designed such in the clear it is important for the GSS API mechanisms to be that an active attacker cannot obtain an authentication with weaker designed such that an active attacker cannot obtain an authentication security properties by modifying the challenges and responses with weaker security properties by modifying the challenges and responses This is a generic design critera for the GSS API mechanisms used under GS2 When a server or client supports multiple GSS API mechanisms each of When a server or client supports multiple GSS API mechanisms each of which has a different security strength it is possible for an active which has a different security strength it is possible for an active attacker to cause a party to use the least secure mechanism attacker to cause a party to use the least secure mechanism supported There are several ways to mitigate this problem supported There are several ways to mitigate this problem 1 Integrity protected transports can be used e g TLS 14 To 1 Integrity protected transports can be used e g TLS 14 To protect against certain tunnel attacks 17 with that solution protect against certain tunnel attacks 18 the GSS API the GSS API mechanisms has to support integrity to provide mechanism need to support integrity to provide support for support for channel bindings channel bindings 2 A client or server which supports mechanisms of different 2 A client or server which supports mechanisms of different strengths should have a configurable minimum strength that it strengths should have a configurable minimum strength that it will use It is not sufficient for this minimum strength check will use It is not sufficient for this minimum strength check to only be on the server since an active attacker can change to only be on the server since an active attacker can change which mechanisms the client sees as being supported causing the which mechanisms the client sees as being supported causing the client to send authentication credentials for its weakest client to send authentication credentials for its weakest supported mechanism supported mechanism This solution however is not guaranteed to the lead to the mutually most secure mechanism and is therefor only recommended as an additional precaution 3 Specify how to use the SPNEGO mechanism in SASL 3 Specify how to use the SPNEGO mechanism in SASL The

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

  • Diff: draft-ietf-sasl-gs2-05.txt - draft-ietf-sasl-gs2-06.txt
    of improvements over the previous SASL GSS API mechanism it is more general uses fewer messages for the mechanism it is more general uses fewer messages for the authentication phase in some cases and supports a SASL specific authentication phase in some cases and supports a SASL specific skipping to change at page 16 line 30 skipping to change at page 16 line 30 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 Send token 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 wrap length 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 wrap length GS2 Wrap client qop client maxbuf GS2 Wrap client qop client maxbuf authzid 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 Because GSS API authentication is initiated by the client the length field will be 0 in the initial token from the server to the client field will be 0 in the initial token from the server to the client when the protocol profile does not support additional information to when the protocol profile does not support additional information to be sent together with the authentication request be sent together with the authentication request skipping to change at page 31 line 44 skipping to change at page 31 line 44 ISO Standard 8824 December 1990 ISO Standard 8824 December 1990 16 2 Informative References 16 2 Informative References 9 Mockapetris P Domain names concepts and facilities 9 Mockapetris P Domain names concepts and facilities STD 13 RFC 1034 November 1987 STD 13 RFC 1034 November 1987 10 Linn J The Kerberos Version 5 GSS API Mechanism RFC 1964 10 Linn J The Kerberos Version 5 GSS API Mechanism RFC 1964 June 1996 June 1996 11 Baize E and D Pinkas The Simple and Protected GSS API 11 Zhu L Leach P Jaganathan K and W Ingersoll The Negotiation Mechanism RFC 2478 December 1998 Simple and Protected Generic Security Service Application Program Interface GSS API Negotiation Mechanism RFC 4178 October 2005 12 Melnikov A The Kerberos V5 GSSAPI Simple Authentication 12 Melnikov A The Kerberos V5 GSSAPI Simple Authentication and Security Layer SASL Mechanism RFC 4752 November 2006 and Security Layer SASL Mechanism RFC 4752 November 2006 13 Adams C The Simple Public Key GSS API Mechanism SPKM 13 Adams C The Simple

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

  • Diff: draft-ietf-sasl-gs2-04.txt - draft-ietf-sasl-gs2-05.txt
    function are defined The first pair is used when the client sends the GSS Wrap token first and first pair is used when the client sends the Wrap token first and the the server responds The other pair is used when the server sends server responds The other pair is used when the server sends the the GSS Wrap token first and the client responds Wrap token first and the client responds The inputs below are passed to GSS Wrap with conf flag set to FALSE The inputs below are passed to GS2 Wrap and the output is used as and the Wrap token will be the generated output message the Wrap token value Some fields in the input formats are optional indicated by brackets Some fields in the input formats are optional indicated by brackets and and explained by the text below and and explained by the text below 4 3 1 Client first GSS Wrap input 4 3 1 The GS2 Wrap function The input to GSS Wrap when the client sends a Wrap token field first 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 is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 client qops client maxbuf client qops client maxbuf channel binding length channel binding length client cbqops channel binding data client cbqops channel binding data skipping to change at page 13 line 10 skipping to change at page 13 line 24 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 5 The authorization identity is not terminated with the NUL U 0000 character Servers identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 MUST validate that the authorization identity is valid UTF 8 4 3 2 Server last GSS Wrap input 4 3 3 Server last GS2 Wrap input The input to GS S Wrap when the server sends a Wrap token field after The input to GS 2 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 server qop server maxbuf server qop server maxbuf The server qop field integer indicate the selected quality of The server qop field integer indicate the selected quality of skipping to change at page 13 line 34 skipping to change at page 13 line 48 9 9 The server maxbuf field indicate the maximum protected data buffer The server maxbuf field indicate the maximum protected data buffer size the server can receive in network byte order It MUST be 0 if 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 the server doesn t advertise support for any security layer the client MUST verify this Small values can make it impossible for 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 client to send any protected message to the server due to the overhead added by GSS Wrap and the client MAY reject the overhead added by GSS Wrap and the client MAY reject the authentication if it detects this situation authentication if it detects this situation 4 3 3 Server first GSS Wrap input 4 3 4 Server first GS2 Wrap input The input to GS S Wrap when the server sends the Wrap token first is The input to GS 2 Wrap when the server sends the Wrap token first is as follows as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 server qops server maxbuf server qops server maxbuf server cbqops channel binding data server cbqops channel binding data skipping to change at page 14 line 12 skipping to change at page 14 line 27 The server maxbuf is the same as above The server maxbuf is the same as above The optional field server cbqops indicate the server s preferred The optional field server cbqops indicate the server s preferred quality of protection if channel binding negotiation succeeds The quality of protection if channel binding negotiation succeeds The quality of protection values are defined in section 9 quality of protection values are defined in section 9 The optional field channel binding data contain the actual channel The optional field channel binding data contain the actual channel binding data binding data 4 3 4 Client last GSS Wrap input 4 3 5 Client last GS2 Wrap input The input to GS S Wrap when the clients sends a Wrap token field The input to GS 2 Wrap when the clients sends a Wrap token field after receiving the Wrap token in the previous section from the after receiving the Wrap token in the previous section from the server is as follows server is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 client qop client maxbuf client qop client maxbuf authzid authzid skipping to change at page 16 line 15 skipping to change at page 16 line 15 6 Protocol Overview 6 Protocol Overview This section describe several high level protocol exchanges The This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur examples and other exchanges are permitted and will occur An informal pseudo language is used to describe the packets sent An informal pseudo language is used to describe the packets sent below In particular when GSS Wrap is mentioned below it refer below GS2 Wrap refer to the operation of calling GS2 Wrap on the to the operation of calling GSS Wrap on the indicated fields indicated fields formatted in the structures described earlier formatted in the structures described earlier GSS Init sec context and GSS Accept sec context refer to the context token generated by calling the respective function The GS2 SASL Message is denoted as Context token Wrap token and the length fields are not mentioned An authentication exchange using GS2 may look like An authentication exchange using GS2 may look like C Request authentication exchange C Request authentication exchange S Send length 0 token S Send token C Send length 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 length GSS Accept sec context send GSS Accept sec context GSS Wrap server qops server maxbuf wrap length GS2 Wrap server qops server maxbuf C After PROT READY is set C After PROT READY is set send length GSS Init sec context send GSS Init sec context GSS Wrap client qop client maxbuf authzid wrap length GS2 Wrap client qop client maxbuf S Send length GSS Accept sec context token authzid C Send length GSS Init sec context token S Send GSS Accept 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 Because GSS API authentication is initiated by the client the length field will be 0 in the initial token from the server to the client field will be 0 in the initial token from the server to the client when the protocol profile does not support additional information to when the protocol profile does not support additional information to be sent together with the authentication request be sent together with the authentication request The next example illustrate when the client sends its Wrap token The next example illustrate when the client sends its Wrap token first first C Request authentication exchange C Request authentication exchange S Send length 0 token S Send token C Send length 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 length GSS Init sec context send GSS Init sec context GSS 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 length GSS Accept sec context send GSS Accept sec context GSS Wrap server qop server maxbuf GS2 Wrap server qop server maxbuf C Send length GSS Init sec context token C Send GSS Init sec context token S Send length GSS Accept sec context token S Send GSS Accept sec context token S Outcome of authentication exchange S Outcome of authentication exchange If the protocol profile support the optional initial client response If the protocol profile support the optional initial client response the first empty message can be optimized away and then the protocol the first empty message can be optimized away and then the protocol exchange will look like exchange will look like C Request authentication exchange and C Request authentication exchange and send length GSS Init sec context token send GSS Init sec context token S Send length GSS Accept sec context token S Send GSS Accept sec context token S Outcome of authentication exchange S Outcome of authentication exchange If the protocol profile can also send additional information when If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol indicating the outcome of the authentication then the protocol exchange will look like exchange will look like C Request authentication exchange and C Request authentication exchange and send length GSS Init sec context token send GSS Init sec context token S Send length GSS Accept sec context token S Send GSS Accept sec context token C Send length GSS Init sec context token C Send GSS Init sec context token S Indicate successful authentication and S Indicate successful authentication and send length GSS Accept sec context token send GSS Accept sec context token as additional information as additional information If the PROT READY flag is never set by the GSS API mechanism the If the PROT READY flag is never set by the GSS API mechanism the GS S Wrap message will be sent after the context has been established GS 2 Wrap message will be sent after the context has been established The protocol may look like The protocol may look like C Request authentication exchange C Request authentication exchange S GSS Accept sec context returns GSS S COMPLETE and outputs S GSS Accept sec context returns GSS S COMPLETE and outputs a token send length context token a token send GS2 Wrap server qops server maxbuf GSS Wrap server qops server maxbuf C GSS Init sec context returns GSS S COMPLETE and does not C GSS Init sec context returns GSS S COMPLETE and does not output a token send output a token send length 0 context token GS2 Wrap client qop client maxbuf GSS Wrap client qop client maxbuf channel binding length 0 authzid channel binding length 0 authzid S Outcome of authentication exchange S Outcome of authentication exchange Alternatively if the client finishes first it may look like Alternatively if the client finishes first it may look like C Request authentication exchange C Request authentication exchange C GSS Init sec context returns GSS S COMPLETE and outputs a C GSS Init sec context returns GSS S COMPLETE and outputs a token send length context token token send GS2 Wrap client qops client maxbuf GSS Wrap client qops client maxbuf channel binding length 0 authzid channel binding length 0 authzid S GSS Accept sec context returns GSS S COMPLETE and does not S GSS Accept sec context returns GSS S COMPLETE and does not output a token send length context token output a token send GS2 Wrap server qop server maxbuf GSS Wrap server qop server maxbuf channel binding length 0 channel binding length 0 S Outcome of authentication exchange S Outcome of authentication exchange Adding channel bindings to the last examples gives the following Adding channel bindings to the last examples gives the following situation Here the client request confidentiality for the complex situation Here the client request confidentiality for the application data if channel binding fails but no SASL security layer application data if channel binding fails but no SASL security layer if channel binding negotiation succeeds if channel binding negotiation succeeds C Request authentication exchange C Request authentication exchange C GSS Init sec context returns GSS S COMPLETE and outputs a C GSS Init sec context returns GSS S COMPLETE and outputs a token send length context token token send GSS Init sec context GSS Wrap client qops 0x04 client maxbuf GS2 Wrap client qops 0x04 client maxbuf channel binding length n channel binding length n client cbqops 0x01 channel binding data client cbqops 0x01 channel binding data authzid authzid S GSS Accept sec context returns GSS S COMPLETE and does not S GSS Accept sec context returns GSS S COMPLETE and does not output a token send length context token output a token send GSS Wrap server qop server maxbuf GS2 Wrap server qop server maxbuf channel binding length 0 channel binding length 0 S Outcome of authentication exchange S Outcome of authentication exchange If the protocol support initial data from the client and the If the protocol support initial data from the client and the PROT READY flag is set in the client after the first call to PROT READY flag is set in the client after the first call to GSS Init sec context and the server can send additional data to the GSS Init sec context and the server can send additional data to the client when indicating successful authentication the following client when indicating successful authentication the following protocol exchange will occur protocol exchange will occur C Request authentication exchange and C Request authentication exchange and send length GSS Init

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

  • Diff: draft-ietf-sasl-gs2-03.txt - draft-ietf-sasl-gs2-04.txt
    and re group them in groups of 5 and convert them back to decimal which results in these computations hex 82 d2 73 25 76 6b d6 c8 45 aa binary 10000010 11010010 01110011 00100101 01110110 01101011 11010110 11001000 01000101 10101010 binary in groups of 5 10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011 01100 10000 10001 01101 01010 decimal of each group 16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10 Translating each decimal value using table 3 in Base32 6 yields the character sequence QLJHGJLWNPLNQRNK Thus the SASL mechanism name for the Kerberos V5 GSSAPI mechanism is GS2 QLJHGJLWNPLNQRNK 4 SASL Authentication Exchange Message Format 4 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 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 5 line 38 skipping to change at page 8 line 45 The Context token field if present contain a GSS API context The Context token field if present contain a GSS API context establishment token generated by GSS Init sec context or establishment token generated by GSS Init sec context or GSS Accept sec context GSS Accept sec context The Wrap token field if present contain the output generated by The Wrap token field if present contain the output generated by GSS Wrap GSS Wrap The fields need not be aligned to 32 bit a boundary There is no The fields need not be aligned to 32 bit a boundary There is no padding between fields padding between fields Messages shorter than or equal to 12 octets are invalid From that Messages shorter than or equal to 8 octets are invalid From that it it follows that not both of the Context token length and the Wrap follows that at least one of the Context token length and the Wrap token length integers can be zero in a particular message If the token length integers MUST be non zero in a particular message If sum of the length integers is longer than the entire message size the sum of the length integers is longer than the entire message minus 8 octets for the length fields the message is invalid size minus 8 octets for the length fields the message is invalid During any successful authentication exchange the client and server During any successful authentication exchange the client and server will each send exactly one non empty Wrap token will each send exactly one non empty Wrap token Conforming implementations MUST NOT send additional data after the Conforming implementations MUST NOT send additional data after the above message syntax and MUST ignore additional data To above message syntax and MUST ignore additional data To illustrate implementations MUST NOT assume that the last Wrap token illustrate implementations MUST NOT assume that the last Wrap token length octets of the packet correspond to the Wrap token because length octets of the packet correspond to the Wrap token because that would be incorrect if the packet contained additional data not that would be incorrect if the packet contained additional data not described by this document described by this document skipping to change at page 6 line 52 skipping to change at page 10 line 10 or as additional information to the outcome of the authentication or as additional information to the outcome of the authentication The client pass the context token to another call to The client pass the context token to another call to GSS Init sec context repeating the procedure until GSS S COMPLETE GSS Init sec context repeating the procedure until GSS S COMPLETE is returned or authentication is aborted is returned or authentication is aborted If the server sent a non empty Wrap token the context token is If the server sent a non empty Wrap token the context token is processed before processing the other tokens This is required processed before processing the other tokens This is required because GSS Unwrap may need the context to be in the state it is because GSS Unwrap may need the context to be in the state it is after the Context token in the message has been processed after the Context token in the message has been processed When GSS Init sec context returns GSS S COMPLETE the client examines When GSS Init sec context returns GSS S COMPLETE the client MUST the context to ensure that it provides a level of protection examine the context to ensure that it provides a level of protection permitted by the client s security policy permitted by the client s security policy 4 2 2 Server side 4 2 2 Server side The server passes the first context token to GSS Accept sec context The server passes the first context token to GSS Accept sec context as input token setting input context handle to GSS C NO CONTEXT as input token setting input context handle to GSS C NO CONTEXT initially the chan binding set to NULL and a suitable initially the chan binding set to NULL and a suitable acceptor cred handle see below acceptor

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

  • Diff: draft-ietf-sasl-gs2-01.txt - draft-ietf-sasl-gs2-02.txt
    data registered the chan binding set to NULL and acceptor cred handle depending on the Native Channel Binding bit and acceptor cred handle equal to output cred handle from GSS Acquire cred called with equal to output cred handle from GSS Acquire cred called with desired name equal to output name from GSS Import name with desired name equal to output name from GSS Import name with input name type of GSS C NT HOSTBASED SERVICE and input name string input name type of GSS C NT HOSTBASED SERVICE and input name string of service hostname where service is the service name specified of service hostname where service is the service name specified in the protocol s profile and hostname is the fully qualified host in the protocol s profile and hostname is the fully qualified host name of the server The server must pass any resulting challenge name of the server The server pass any resulting challenge from the from the client to another call to GSS Accept sec context repeating client to another call to GSS Accept sec context repeating the the actions in this paragraph until GSS S COMPLETE is returned or actions in this paragraph until GSS S COMPLETE is returned or authentication is aborted If the client supply data beyond the authentication is aborted If the client supply data beyond the context token the context token should be processed first and then context token the context token is processed first and then the the overflow data should be passed to GSS Unwrap and the unwrapped overflow data is passed to GSS Unwrap and the unwrapped data data should be interpreted During the authentication exchange the interpreted During the authentication exchange the server will server will generate one Wrap token using GSS Wrap generate one Wrap token using GSS Wrap 4 4 Wrap Token 4 3 Wrap Token The Wrap token MUST NOT be sent before the PROT READY flag has been The Wrap token MUST NOT be sent before the PROT READY flag has been set locally by GSS Init sec context or Gss Accept sec context or 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 if the PROT READY flag is never set before the context has been fully established The GSS Wrap token does not have to be sent fully established The GSS Wrap token does not have to be sent directly when the PROT READY flag is set During any exchange directly when the PROT READY flag is set During any exchange exactly one GSS Wrap token is sent in each direction The input to exactly one GSS Wrap token is sent in each direction The input to the GSS Wrap function MUST follow the format described below If not the GSS Wrap function MUST follow the format described below If not exactly one GSS Wrap token is received by the client and by the exactly one GSS Wrap token is received by the client and by the server the authentication MUST fail server the authentication MUST fail skipping to change at page 7 line 47 skipping to change at page 7 line 15 when the server sends the GSS Wrap token first and the client when the server sends the GSS Wrap token first and the client responds responds The input formats below are passed to GSS Wrap with conf flag set to The input formats below are passed to GSS Wrap with conf flag set to FALSE and the Wrap token output will be the generated FALSE and the Wrap token output will be the generated output message output message Some fields in the input formats are optional indicated by brackets Some fields in the input formats are optional indicated by brackets and and explained by the text below and and explained by the text below 4 4 1 Wrap Token Input For Client R equests 4 3 1 GSS Wrap input for client r equests The input to GSS Wrap when the client sends the GSS Wrap token first The input to GSS Wrap when the client sends the GSS Wrap token first is as follows is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 client qops client maxbuf client qops client maxbuf channel binding length channel binding length skipping to change at page 8 line 41 skipping to change at page 8 line 8 The optional field channel binding data is present only if The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel channel binding length is non zero and contain the actual channel binding data binding data The optional field authzid contain the authorization identity The The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 6 The authorization authorization identity is encoded using UTF 8 6 The authorization identity is not terminated with the NUL U 0000 character Servers identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 MUST validate that the authorization identity is valid UTF 8 4 4 2 WraP Token Input For Server R esponses 4 3 2 GSS Wrap input for server r esponses The data format for input to GSS Wrap when the server responds to the The data format for input to GSS Wrap when the server responds to the previous GSS Wrap token data is as follows previous GSS Wrap token data is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 server qop server maxbuf server qop server maxbuf The server qop field integer indicate the selected quality of The server qop field integer indicate the selected quality of protection protection The server maxbuf field indicate the maximum data buffer size the The server maxbuf field indicate the maximum data buffer size the server can receive It MUST be 0 if the server doesn t advertise server can receive It MUST be 0 if the server doesn t advertise support for any security layer the client MUST verify this support for any security layer the client MUST verify this 4 4 3 Wrap Token Input For Server R equests 4 3 3 GSS Wrap input for server r equests The data format for input to GSS Wrap when the server sends the The data format for input to GSS Wrap when the server sends the GSS Wrap token first is as follows GSS Wrap token first is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 server qops server maxbuf server qops server maxbuf channel binding length channel binding length skipping to change at page 9 line 43 skipping to change at page 9 line 11 The optional field server cbqops is present only if The optional field server cbqops is present only if channel binding length is non zero and indicate the server s channel binding length is non zero and indicate the server s preferred quality of protection if channel binding negotiation preferred quality of protection if channel binding negotiation succeeds succeeds 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 4 4 4 Wrap Token Input For Client R esponses 4 3 4 GSS Wrap input for client r esponses The data format for input to GSS Wrap when the client responds to the The data format for input to GSS Wrap when the client responds to the previous token is as follows previous token is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 client qop client maxbuf client qop client maxbuf authzid authzid The client qop field is the selected quality of protection The client qop field is the selected quality of protection The client maxbuf and authzid fields are as above The client maxbuf and authzid fields are as above 5 Channel Bindings 5 Channel Bindings This section is tentative further discussion on the topic This The GS2 mechanism provide its own channel binding mechanism instead was written to provide an example of how the details of how one of using the chan binding parameter in the GSS API context approach to this concept could look like There are other approaches functions The reason for this is that the GS2 mechanism provide an that may be preferable option to proceed even if the channel bindings does not match The GSS API framework specifies that authentication cannot proceed if The GS2 mechanism provide its own token field for channel bindings channel bindings does not match in addition to the chan binding parameter in the GSS API context functions The reason for this is that the GS2 mechanism wish to provide an option to proceed even if the channel bindings does not match The GSS API framework specifies that authentication cannot proceed if channel bindings does not match The GSS API framework also does not specify the kind of privacy layer the channel binding should be transferred under thus making it possible for attackers to modify it to always make channel binding negotiation succeed The client can select using the Native Channel Bindings bit whether it wishes to use the chan bindings parameter in the GSS API layer or not If it wishes to use this it is not possible to continue after a failed channel binding negotiation A client that wish to continue with the authentication even if the channel bindings does not match set the Native Channel Binding bit to 0 It MUST use the channel binding field in the GS2 token It MUST set the chan binding parameter in the calls to GSS Init sec context to GSS Accept sec context to NULL The application MUST set the client qops field to include privacy protection to protect the SASL application data and MAY set the client cbqops to no security layer to avoid performance degradation due to two security layers If a client do not wish to continue the authentication if channel binding negotiation fails or wishes to use the channel binding in the GSS API layer it will set the Native Channel Binding bit to 1 in its first token It MUST use both the channel binding field in the GS2 token and the chan binding parameter in the calls to GSS Init sec context and GSS Accept sec context The authentication will fail in the GSS API layer if the channel bindings does not match and thus the client qops and client cbqops MUST be set to the same value It MAY be set to no security layer to avoid performance degradation due to two security layers For TLS the channel binding data is specified in the next section For other security layers channel binding data will have to specified elsewhere and this specification will have to be updated with explicit considerations All channel bindings should go into a separate document 5 1 Name Of Tls Channel For Use As Channel Binding The TLS Pseudo Random Function PRF generate using the constant Client and servers MUST set the chan binding parameter in the calls string TLS channel binding and based on the master secret and the to GSS Init sec context to GSS Accept sec context respectively to random values established during a TLS handshake a 64 octet string NULL that make up the SASL channel binding data Using the terminology of TLS 13 the channel binding data is Implementations SHOULD set the client cbqops and server cbqops to computed as follows no security layer and instead depend on the session security afforded by the bound in channel SASL channel binding Use of no SASL security layers in combination with channel binding PRF SecurityParameters master secret should provide better performance than using SASL security layers TLS channel binding over secure channels and better security characteristics than using SecurityParameters server random no SASL security layers over secure channels without channel binding SecurityParameters client random 0 64 The derived data is intended to be used as a name of the TLS channel For more discussions of channel bindings and the syntax of the that is cryptographically bound to the channel for use in channel binding data for various security protocols see 7 authentication mechanisms tunneled over TLS 6 Protocol Overview 6 Protocol Overview This section describe several high level protocol exchanges The This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur examples and other exchanges are permitted and will occur skipping to change at page 14 line 6 skipping to change at page 12 line 32 C GSS Init sec context returns GSS S COMPLETE and outputs a C GSS Init sec context returns GSS S COMPLETE and outputs a token send length context token token send length context token GSS Wrap client qops client maxbuf GSS Wrap client qops client maxbuf channel binding length 0 authzid channel binding length 0 authzid S GSS Accept sec context returns GSS S COMPLETE and does not S GSS Accept sec context returns GSS S COMPLETE and does not output a token send length context token output a token send length context token GSS Wrap server qop server maxbuf GSS Wrap server qop server maxbuf channel binding length 0 channel binding length 0 S Outcome of authentication exchange S Outcome of authentication exchange Adding channel bindings to the last examples gives the following situation Here the client request confidentiality for the application data if channel binding fails but no SASL security layer if channel binding negotiation succeeds C Request authentication exchange C GSS Init sec context returns GSS S COMPLETE and outputs a token send length context token GSS Wrap client qops 0x04 client maxbuf channel binding length n client cbqops 0x01 channel binding data authzid S GSS Accept sec context returns GSS S COMPLETE and does not output a token send length context token GSS Wrap server qop server maxbuf channel binding length 0 S Outcome of authentication exchange If the protocol support initial data from the client and the If the protocol support initial data from the client and the PROT READY flag is set in the client after the first call to PROT READY flag is set in the client after the first call to GSS Init sec context and the server can send additional data to the GSS Init sec context and the server can send additional data to the client when indicating successful authentication the following client when indicating successful authentication the following protocol exchange will occur protocol exchange will occur C Request authentication exchange and C Request authentication exchange and send length GSS Init sec context send length GSS Init sec context GSS Wrap client qops client maxbuf GSS Wrap client qops client maxbuf channel binding length 0 authzid token channel binding length 0 authzid token skipping to change

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

  • Diff: draft-ietf-sasl-gs2-00.txt - draft-ietf-sasl-gs2-01.txt
    If the client will be requesting a security integ req flag of TRUE If the client will be requesting a security layer providing confidentiality protection it MUST also supply to layer providing confidentiality protection it MUST also supply to the GSS Init sec context a conf req flag of TRUE If the GSS Init sec context a conf req flag of TRUE If GSS Init sec context returns GSS S CONTINUE NEEDED then the client GSS Init sec context returns GSS S CONTINUE NEEDED then the client should expect the server to issue a token in a subsequent challenge should expect the server to issue a token in a subsequent challenge skipping to change at page 6 line 13 skipping to change at page 6 line 44 GSS S COMPLETE is returned or authentication is aborted If the GSS S COMPLETE is returned or authentication is aborted If the server supply data beyond the context token the context token should server supply data beyond the context token the context token should be processed first and then the overflow data should be passed to be processed first and then the overflow data should be passed to GSS Unwrap and the unwrapped data should be interpreted During the GSS Unwrap and the unwrapped data should be interpreted During the authentication exchange the client will generate one Wrap token authentication exchange the client will generate one Wrap token using GSS Wrap using GSS Wrap The server passes the first client response to GSS Accept sec context The server passes the first client response to GSS Accept sec context as input token setting input context handle to 0 initially as input token setting input context handle to 0 initially mech type of the GSSAPI mechanism for which this SASL mechanism is mech type of the GSSAPI mechanism for which this SASL mechanism is registered any chan binding if requested by the application XXX registered the chan binding set to NULL or the channel binding data and acceptor cred handle equal to output cred handle from depending on the Native Channel Binding bit and acceptor cred handle GSS Acquire cred called with desired name equal to output name from equal to output cred handle from GSS Acquire cred called with GSS Import name with input name type of GSS C NT HOSTBASED SERVICE desired name equal to output name from GSS Import name with and input name string of service hostname where service is the input name type of GSS C NT HOSTBASED SERVICE and input name string service name specified in the protocol s profile and hostname is of service hostname where service is the service name specified the fully qualified host name of the server The server must pass in the protocol s profile and hostname is the fully qualified host any resulting challenge from the client to another call to name of the server The server must pass any resulting challenge GSS Accept sec context repeating the actions in this paragraph from the client to another call to GSS Accept sec context repeating until GSS S COMPLETE is returned or authentication is aborted If the actions in this paragraph until GSS S COMPLETE is returned or the client supply data beyond the context token the context token authentication is aborted If the client supply data beyond the should be processed first and then the overflow data should be context token the context token should be processed first and then passed to GSS Unwrap and the unwrapped data should be interpreted the overflow data should be passed to GSS Unwrap and the unwrapped During the authentication exchange the server will generate one Wrap data should be interpreted During the authentication exchange the token using GSS Wrap server will generate one Wrap token using GSS Wrap 4 3 Wrap t oken 4 4 Wrap T oken The Wrap token MUST NOT be sent before the PROT READY flag has been The Wrap token MUST NOT be sent before the PROT READY flag has been set locally by GSS Init sec context or Gss Accept sec context or 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 if the PROT READY flag is never set before the context has been fully established The GSS Wrap token does not have to be sent fully established The GSS Wrap token does not have to be sent directly when the PROT READY flag is set During any exchange directly when the PROT READY flag is set During any exchange exactly one GSS Wrap token is sent in each direction The input to exactly one GSS Wrap token is sent in each direction The input to the GSS Wrap function MUST follow the format described below If not the GSS Wrap function MUST follow the format described below If not exactly one GSS Wrap token is received by the client and by the exactly one GSS Wrap token is received by the client and by the server the authentication MUST fail server the authentication MUST fail skipping to change at page 7 line 18 skipping to change at page 7 line 47 when the server sends the GSS Wrap token first and the client when the server sends the GSS Wrap token first and the client responds responds The input formats below are passed to GSS Wrap with conf flag set to The input formats below are passed to GSS Wrap with conf flag set to FALSE and the Wrap token output will be the generated FALSE and the Wrap token output will be the generated output message output message Some fields in the input formats are optional indicated by brackets Some fields in the input formats are optional indicated by brackets and and explained by the text below and and explained by the text below 4 3 1 Wrap token input for client r equests 4 4 1 Wrap Token Input For Client R equests The input to GSS Wrap when the client sends the GSS Wrap token first The input to GSS Wrap when the client sends the GSS Wrap token first is as follows is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 client qops client maxbuf client qops client maxbuf channel binding length channel binding length skipping to change at page 8 line 10 skipping to change at page 8 line 41 The optional field channel binding data is present only if The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel channel binding length is non zero and contain the actual channel binding data binding data The optional field authzid contain the authorization identity The The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 6 The authorization authorization identity is encoded using UTF 8 6 The authorization identity is not terminated with the NUL U 0000 character Servers identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 MUST validate that the authorization identity is valid UTF 8 4 3 2 Wrap token input for server r esponses 4 4 2 WraP Token Input For Server R esponses The data format for input to GSS Wrap when the server responds to the The data format for input to GSS Wrap when the server responds to the previous GSS Wrap token data is as follows previous GSS Wrap token data is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 server qop server maxbuf server qop server maxbuf The server qop field integer indicate the selected quality of The server qop field integer indicate the selected quality of protection protection The server maxbuf field indicate the maximum data buffer size the The server maxbuf field indicate the maximum data buffer size the server can receive It MUST be 0 if the server doesn t advertise server can receive It MUST be 0 if the server doesn t advertise support for any security layer the client MUST verify this support for any security layer the client MUST verify this 4 3 3 Wrap token input for server r equests 4 4 3 Wrap Token Input For Server R equests The data format for input to GSS Wrap when the server sends the The data format for input to GSS Wrap when the server sends the GSS Wrap token first is as follows GSS Wrap token first is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 server qops server maxbuf server qops server maxbuf channel binding length channel binding length skipping to change at page 9 line 12 skipping to change at page 9 line 43 The optional field server cbqops is present only if The optional field server cbqops is present only if channel binding length is non zero and indicate the server s channel binding length is non zero and indicate the server s preferred quality of protection if channel binding negotiation preferred quality of protection if channel binding negotiation succeeds succeeds 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 4 3 4 Wrap token input for client r esponses 4 4 4 Wrap Token Input For Client R esponses The data format for input to GSS Wrap when the client responds to the The data format for input to GSS Wrap when the client responds to the previous token is as follows previous token is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 client qop client maxbuf client qop client maxbuf authzid authzid The client qop field is the selected quality of protection The client qop field is the selected quality of protection The client maxbuf and authzid fields are as above The client maxbuf and authzid fields are as above 5 Protocol overview 5 Channel Bindings This section is tentative further discussion on the topic This was written to provide an example of how the details of how one approach to this concept could look like There are other approaches that may be preferable The GS2 mechanism provide its own token field for channel bindings in addition to the chan binding parameter in the GSS API context functions The reason for this is that the GS2 mechanism wish to provide an option to proceed even if the channel bindings does not match The GSS API framework specifies that authentication cannot proceed if channel bindings does not match The GSS API framework also does not specify the kind of privacy layer the channel binding should be transferred under thus making it possible for attackers to modify it to always make channel binding negotiation succeed The client can select using the Native Channel Bindings bit whether it wishes to use the chan bindings parameter in the GSS API layer or not If it wishes to use this it is not possible to continue after a failed channel binding negotiation A client that wish to continue with the authentication even if the channel bindings does not match set the Native Channel Binding bit to 0 It MUST use the channel binding field in the GS2 token It MUST set the chan binding parameter in the calls to GSS Init sec context to GSS Accept sec context to NULL The application MUST set the client qops field to include privacy protection to protect the SASL application data and MAY set the client cbqops to no security layer to avoid performance degradation due to two security layers If a client do not wish to continue the authentication if channel binding negotiation fails or wishes to use the channel binding in the GSS API layer it will set the Native Channel Binding bit to 1 in its first token It MUST use both the channel binding field in the GS2 token and the chan binding parameter in the calls to GSS Init sec context and GSS Accept sec context The authentication will fail in the GSS API layer if the channel bindings does not match and thus the client qops and client cbqops MUST be set to the same value It MAY be set to no security layer to avoid performance degradation due to two security layers For TLS the channel binding data is specified in the next section For other security layers channel binding data will have to specified elsewhere and this specification will have to be updated with explicit considerations All channel bindings should go into a separate document 5 1 Name Of Tls Channel For Use As Channel Binding The TLS Pseudo Random Function PRF generate using the constant string TLS channel binding and based on the master secret and the random values established during a TLS handshake a 64 octet string that make up the SASL channel binding data Using the terminology of TLS 13 the channel binding data is computed as follows SASL channel binding PRF SecurityParameters master secret TLS channel binding SecurityParameters server random SecurityParameters client random 0 64 The derived data is intended to be used as a name of the TLS channel that is cryptographically bound to the channel for use in authentication mechanisms tunneled over TLS 6 Protocol Overview This section describe several high level protocol exchanges The This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur examples and other exchanges are permitted and will occur An authentication exchange using GS2 may look like An authentication exchange using GS2 may look like skipping to change at page 12 line 24 skipping to change at page 14 line 24 GSS Wrap client qops client maxbuf GSS Wrap client qops client maxbuf channel binding length 0 authzid token channel binding length 0 authzid token S Indicate successful authentication and S Indicate successful authentication and send length GSS Accept sec context send length GSS Accept sec context GSS Wrap server qop server maxbuf token GSS Wrap server qop server maxbuf token as additional information as additional information The last example illustrate the optimal round trip wise The last example illustrate the optimal round trip wise authentication possible using this protocol authentication possible using this protocol 6 Authentication Conditions 7 Authentication Conditions Authentication MUST NOT succeed if any one of the following Authentication MUST NOT succeed if any one of the following conditions are true conditions are true o An invalid SASL token is received i e length shorter than 4 o An invalid SASL token is received i e length shorter than 4 octets octets o GSS Init Accept sec context return anything other than o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS

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

  • GNU SASL Library - Libgsasl - GNU Project - Free Software Foundation
    fully implemented in both client and server mode The NTLM mechanism is implemented in client mode only DIGEST MD5 and GSSAPI are implemented in client and server mode but not all features are supported e g no security layers nor fast resumption GS2 KRb5 is supported in the experimental branch The library has been used in production for several years and should be considered mature GNU SASL has been ported to Windows and there are some resources around this effort Installing under Windows Kerberos on Windows Pre built Windows binaries Free software projects using GNU SASL include GNU Emacs in the Gnus MUA GNU Mailutils GNU Anubis MSMTP MPOP VMIME Vortex Library a BEEP stack Jabberd2 a XMPP server Let us know about more free software projects that use GNU SASL Support A mailing list where GNU SASL users may help each other exists and you can reach it by sending e mail to help gsasl gnu org Archives of the mailing list discussions and an interface to manage subscriptions is available through the World Wide Web at http lists gnu org mailman listinfo help gsasl If you are interested in paid support of GNU SASL or sponsor the development please contact me If you provide paid services for GNU SASL and would like to be mentioned here also contact me If you find GNU SASL useful please consider making a donation No amount is too small News Note that new releases are only mentioned here if they introduce a major feature or is significant in some other way Read the help gsasl mailing list if you seek more frequent announcements Information on what is new in the library itself is found in the NEWS and lib NEWS file live version 2010 03 31 GS2 KRB5 is supported in the experimental 1 5 0 release 2009 11 07 SCRAM SHA 1 is now intended for stable use with the version 1 4 release 2009 10 08 As of version 1 3 the library experimentally supports SCRAM SHA 1 2008 08 19 The library can be built as a native Windows Visual Studio project 2008 01 12 Instructions for building GNU SASL under uClinux have been published 2007 10 08 Git repository moved to Savannah you can browse it 2007 07 09 The command line self tests examples etc of GNU SASL are now licensed under the GPL version 3 The library remains licensed under the LGPL version 2 1 2007 06 01 GNU SASL is now developed in git instead of cvs a public repository can be found at repo or cz 2007 04 20 Version 0 2 16 released today will likely be the last release on the 0 2 x branch next we ll focus on implementing GS2 2006 06 14 Newly released version 0 2 13 works well under Windows 2004 11 07 A new major release version 0 2 0 has been released 2004 04 16 The license for the core library and most common mechanisms

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


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

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



  •