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

  • longer than the entire packet size minus 4 octets the packet is invalid 4 2 Context token The format of the Context token field inside the SASL token are defined by the GSS API specifications see GSS Init sec context and GSS Accept sec context The client calls GSS Init sec context passing in input context handle of 0 initially mech type of the GSSAPI mechanism for which this SASL mechanism is registered any chan binding if requested by the application XXX and targ name equal to output name from GSS Import Name called with input name type of GSS C NT HOSTBASED SERVICE and input name string of service hostname where service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server If the client will be requesting a security layer it MUST also supply to the GSS Init sec context a mutual req flag of TRUE a sequence req flag of TRUE and an integ req flag of TRUE If the client will be requesting a security layer providing confidentiality protection it MUST also supply to the GSS Init sec context a conf req flag of TRUE If GSS Init sec context returns GSS S CONTINUE NEEDED then the client should expect the server to issue a token in a subsequent challenge or as additional information to the outcome of the authentication The client must pass the context token to another call to GSS Init sec context repeating the actions in this paragraph until GSS S COMPLETE is returned or authentication is aborted If the Josefsson Expires August 17 2006 Page 5 Internet Draft SASL GS2 February 2006 server supply data beyond the context token the context token should be processed first and then the overflow data should be passed to GSS Unwrap and the unwrapped data should be interpreted During the authentication exchange the client will generate one Wrap token using GSS Wrap The server passes the first client response to GSS Accept sec context as input token setting input context handle to 0 initially mech type of the GSSAPI mechanism for which this SASL mechanism is registered any chan binding if requested by the application XXX and acceptor cred handle equal to output cred handle from GSS Acquire cred called with desired name equal to output name from GSS Import name with input name type of GSS C NT HOSTBASED SERVICE and input name string of service hostname where service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server The server must pass any resulting challenge from the client to another call to GSS Accept sec context repeating the actions in this paragraph until GSS S COMPLETE is returned or authentication is aborted If the client supply data beyond the context token the context token should be processed first and then the overflow data should be passed to GSS Unwrap and the unwrapped data should be interpreted During the authentication exchange the server will generate one Wrap token using GSS Wrap 4 3 Wrap token The Wrap token MUST NOT be sent before the PROT READY flag has been set locally by GSS Init sec context or Gss Accept sec context or if the PROT READY flag is never set before the context has been fully established The GSS Wrap token does not have to be sent directly when the PROT READY flag is set During any exchange exactly one GSS Wrap token is sent in each direction The input to the GSS Wrap function MUST follow the format described below If not exactly one GSS Wrap token is received by the client and by the server the authentication MUST fail If PROT READY is never set by GSS Init sec context or GSS Accept sec context the flag is implied by successful context negotiation This is for GSS API v1 mechanisms that do not support PROT READY This may result in a SASL token consisting of a context token length of 0 and a Wrap token The entity that sends its first Wrap token will have to specify a bitmap of supported and preferred quality of protection schemes The entity that reply to the Wrap tokens will pick a scheme based on the bitmask and local policy Josefsson Expires August 17 2006 Page 6 Internet Draft SASL GS2 February 2006 Four input formats to the GSS Wrap function are defined The first two input formats are used when the client sends the GSS Wrap token first and the server reponds The other two input formats are used when the server sends the GSS Wrap token first and the client responds The input formats below are passed to GSS Wrap with conf flag set to FALSE and the Wrap token output will be the generated output message Some fields in the input formats are optional indicated by brackets and and explained by the text below 4 3 1 Wrap token input for client requests The input to GSS Wrap when the client sends the GSS Wrap token first is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 client qops client maxbuf channel binding length client cbqops channel binding data authzid The client qops integer indicate the client s preferred quality of protection if channel bindings are absent or the negotiation of the channel binding fails The client maxbuf field indicate the maximum protected buffer size the client can receive The channel binding length is a network byte order integer that indicate the length of the channel binding data field The optional field client cbqops is present only if channel binding length is non zero and indicate the client s preferred quality of protection if channel binding negotiation succeeds The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data Josefsson Expires August 17 2006 Page 7 Internet Draft SASL GS2 February 2006 The optional field authzid contain the authorization identity The authorization identity is encoded using UTF 8 6 The authorization identity is not terminated with the NUL U 0000 character Servers MUST validate that the authorization identity is valid UTF 8 4 3 2 Wrap token input for server responses The data format for input to GSS Wrap when the server responds to the previous GSS Wrap token data is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 server qop server maxbuf The server qop field integer indicate the selected quality of protection The server maxbuf field indicate the maximum data buffer size the server can receive It MUST be 0 if the server doesn t advertise support for any security layer the client MUST verify this 4 3 3 Wrap token input for server requests The data format for input to GSS Wrap when the server sends the GSS Wrap token first is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 server qops server maxbuf channel binding length server cbqops channel binding data The server qops field is an integer indicating the server s preferred quality of protection if channel bindings are absent or the negotiation of the channel binding fails The server maxbuf is the same as above The channel binding length is a network byte order integer that indicate the length of the channel binding data field The optional field server cbqops is present only if Josefsson Expires August 17 2006 Page 8 Internet Draft SASL GS2 February 2006 channel binding length is non zero and indicate the server s preferred quality of protection if channel binding negotiation succeeds The optional field channel binding data is present only if channel binding length is non zero and contain the actual channel binding data 4 3 4 Wrap token input for client responses The data format for input to GSS Wrap when the client responds to the previous token is as follows 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 client qop client maxbuf authzid The client qop field is the selected quality of protection The client maxbuf and authzid fields are as above 5 Protocol overview This section describe several high level protocol exchanges The descriptions do not assume any properties of the actual GSS API mechanism Protocol profiles GSS API mechanism specific behaviour and to some extent implementation and policy choices will dictate which packets are sent in what order The protocol exchanges are examples and other exchanges are permitted and will occur An authentication exchange using GS2 may look like Josefsson Expires August 17 2006 Page 9 Internet Draft SASL GS2 February 2006 C Request authentication exchange S Send length 0 token C Send length GSS Init sec context token S After PROT READY is set send length GSS Accept sec context GSS Wrap server qops server maxbuf channel binding length 0 C After PROT READY is set send length GSS Init sec context GSS Wrap client qop client maxbuf authzid S Send length GSS Accept sec context token C Send length GSS Init sec context token S Outcome of authentication exchange Because GSS API authentication is initiated by the client the length field will be 0 in the initial token from the server to the client when the protocol profile do not support additional information to be sent together with the authentication request The next example illustrate when the client sends its Wrap token first C Request authentication exchange S Send length 0 token C Send length GSS Init sec context token C After PROT READY is set send length GSS Init sec context GSS Wrap client qops client maxbuf channel binding length 0 authzid S After PROT READY is set send length GSS Accept sec context GSS Wrap server qop server maxbuf C Send length GSS Init sec context token S Send length GSS Accept sec context token S Outcome of authentication exchange If the protocol profile support the optional initial client response the first empty message can be optimized away and then the protocol exchange will look like Josefsson Expires August 17 2006 Page 10 Internet Draft SASL GS2 February 2006 C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token S Outcome of authentication exchange If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol exchange will look like C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token C Send length GSS Init sec context token S Indicate successful authentication and send length GSS Accept sec context token as additional information If the PROT READY flag is never set by the GSS API mechanism the GSS Wrap message will be sent after the context has been established The protocol may look like C Request authentication exchange S GSS Accept sec context returns GSS S COMPLETE and outputs a token send length context token GSS Wrap server qops server maxbuf channel binding length 0 C GSS Init sec context returns GSS S COMPLETE and does not output a token send length 0 context token GSS Wrap client qop client maxbuf channel binding length 0 authzid S Outcome of authentication exchange Alternatively if the client finishes first it may look like C Request authentication exchange C GSS Init sec context returns GSS S COMPLETE and outputs a token send length context token GSS Wrap client qops client maxbuf channel binding length 0 authzid S GSS Accept sec context returns GSS S COMPLETE and does not output a token send length context token GSS Wrap server qop server maxbuf channel binding length 0 Josefsson Expires August 17 2006 Page 11 Internet Draft SASL GS2 February 2006 S Outcome of authentication exchange If the protocol support initial data from the client and the PROT READY flag is set in the client after the first call to GSS Init sec context and the server can send additional data to the client when indicating successful authentication the following protocol exchange will occur C Request authentication exchange and send length GSS Init sec context GSS Wrap client qops client maxbuf channel binding length 0 authzid token S Indicate successful authentication and send length GSS Accept sec context GSS Wrap server qop server maxbuf token as additional information The last example illustrate the optimal round trip wise authentication possible using this protocol 6 Authentication Conditions Authentication MUST NOT succeed if any one of the following conditions are true o An invalid SASL token is received i e length shorter than 4 octets o GSS Init Accept sec context return anything other than GSS S CONTINUE NEEDED or GSS S COMPLETE o GSS Wrap returns anything other than GSS S COMPLETE o GSS Unwrap returns anything other than GSS S COMPLETE There can t be supplementary status codes in GS2 at this point so any indications of out of order processing or replays should be fatal o The token returned from GSS Unwrap fail to parse correctly e g too short invalid maximum buffer size as the expected Wrap token o Local policy reject the attempt For example client and server can t agree on qop proposal o server side Authorization of client principal i e src name in GSS Acecpt sec context to requested authzid failed 7 GSS API parameters The implementation MAY set any GSSAPI flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy Josefsson Expires August 17 2006 Page 12 Internet Draft SASL GS2 February 2006 8 Security layer bits The security layers and their corresponding bit masks are as follows 1 No security layer 2 Integrity protection Sender calls GSS Wrap with conf flag set to FALSE 4 Confidentiality protection Sender calls GSS Wrap with conf flag set to TRUE Other bit masks may be defined in the future bits which are not understood must be negotiated off Note that SASL negotiates the maximum size of the output message to send Implementations can use the GSS Wrap size limit call to determine the corresponding maximum size input message 9 Interoperability with the GSSAPI mechanism The GSSAPI mechanism 11 describe how the Kerberos V5 GSS API mechanism 9 is used in SASL under the mechanism name GSSAPI The same mechanism may also be used with the GS2 family This causes an interopability problem which is discussed and resolved below 9 1 Interoperability problem If a client or server only support Kerberos V5 under the GSSAPI name and the server or client only support Kerberos V5 under the GS2 family the authentication negotiation will fail 9 2 Resolving the problem If the Kerberos V5 mechanism is supported under GS2 in a server the server SHOULD also support Kerberos V5 through the GSSAPI mechanism to avoid interoperability problems with older clients Reasons for violating this recommendation may include security considerations regarding the absent features in the GS2 mechanism The Kerberos V5 GSSAPI SASL mechanism lack channel bindings which could enable certain tunnel attacks 16 9 3 Additional recommendations It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism rather than through the GSSAPI mechanism if both are available because of the additional features in the GS2 mechanism Josefsson Expires August 17 2006 Page 13 Internet Draft SASL GS2 February 2006 10 Mechanisms that negotiate other mechanisms A GSS API mechanism that negotiate other mechanisms interact badly with the SASL mechanism negotiation There are two problems The first is an interoperability problem and the second is a security concern The problems are described and resolved below 10 1 Interoperability problem If a client implement GSS API mechanism X potentially negotiated through a GSS API mechanism Y and the server also implement GSS API mechanism X negotiated through a GSS API mechanism Z the authentication negotiation will fail 10 2 Security problem If a client s policy is to first prefer GSSAPI mechanism X then non GSSAPI mechanism Y then GSSAPI mechanism Z and if a server supports mechanisms Y and Z but not X then if the client attempts to negotiate mechanism X by using a GSS API mechanism that negotiate other mechanisms such as SPNEGO it may end up using mechanism Z when it should have used mechanism Y For this reason the use of GSS API mechanisms that negotiate other mechanisms are disallowed under GS2 10 3 Resolving the problems GSS API mechanisms that negotiate other mechanisms MUST NOT be used with the GS2 SASL mechanism This specifically exclude negotiating SPNEGO 10 under GS2 The GSS C MA MECH NEGO attribute of GSS Inquire attrs for mech 15 can be used to identify such mechanisms 11 IANA Considerations The IANA is advised that SASL mechanism names starting with GS2 are reserved for SASL mechanisms which conform to this

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



  • Wrap token does not have to be sent directly whenever the PROT READY flag is set If PROT READY is never set by GSS Init sec context or GSS Accept sec context the GSS Wrap messages can be sent after the context has been established In this case the length field will encode the integer 0 indicating that the context token is absent If the context has not been established at that point the authentication MUST fail If the protocol profile support the optional initial client response then the protocol exchange will look like Josefsson Expires May 21 2006 Page 6 Internet Draft SASL GS2 November 2005 C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token C Send length GSS Init sec context token S Send length GSS Accept sec context GSS Wrap server qops server maxbuf token C Send length GSS Init sec context GSS Wrap client qop client maxbuf authzid token S Send length GSS Accept sec context token C Send length GSS Init sec context token S Outcome of authentication exchange If the protocol profile can also send additional information when indicating the outcome of the authentication then the protocol exchange will look like C Request authentication exchange and send length GSS Init sec context token S Send length GSS Accept sec context token C Send length GSS Init sec context token S Send length GSS Accept sec context GSS Wrap server qops server maxbuf token C Send length GSS Init sec context GSS Wrap client qop client maxbuf authzid token S Send length GSS Accept sec context token C Send length GSS Init sec context token C Send length GSS Init sec context token S Indicate successful authentication and send length GSS Accept sec context token as additional information The client MUST verify that GSS Init context return GSS S COMPLETE rather than trust the server s signaling of whether the authentication was successful or not If the server report successful authentication and GSS Init sec context did not return GSS S COMPLETE on the last token the authentication MUST be aborted by the client If the PROT READY flag is never set by the GSS API mechanism the GSS Wrap message will be sent after the context has been established The protocol may look like Josefsson Expires May 21 2006 Page 7 Internet Draft SASL GS2 November 2005 C Request authentication exchange S GSS Accept sec context return GSS S COMPLETE send length GSS Accept sec context token C GSS Init sec context return GSS S COMPLETE send length GSS Init sec context token S Send length 0 GSS Wrap server qops server maxbuf token C Send length 0 GSS Wrap client qop client maxbuf authzid token S Outcome of authentication exchange Alternatively if the client finishes first it may look like C Request authentication exchange C GSS Init sec context return GSS S COMPLETE send length GSS Init sec context token S GSS Accept sec context return GSS S COMPLETE send length GSS Accept sec context token C Send length 0 GSS Wrap client qops client maxbuf authzid token S Send length 0 GSS Wrap server qop server maxbuf token C Empty Response S Outcome of authentication exchange If the entity the finish first does not wish to send its GSS Wrap message first it send an empty token to indicate this Only one empty token is permitted more than one MUST lead to authentication failure Empty tokens are not permitted during the initial conext establishment The following figure illustrate this scenario C Request authentication exchange C GSS Init sec context return GSS S COMPLETE send length GSS Init sec context token S GSS Accept sec context return GSS S COMPLETE send length GSS Accept sec context token C Empty Response S Send length 0 GSS Wrap server qops server maxbuf token C Send length 0 GSS Wrap client qop client maxbuf authzid token S Outcome of authentication exchange This alter which side chose the resulting quality of protection Earlier the client sent a bit mask of which quality of protection he support prefer and the server chose one Now the server send a bit mask of which quality of protections it support prefer and the client chose one Implementations are encouraged to pick the Josefsson Expires May 21 2006 Page 8 Internet Draft SASL GS2 November 2005 strongest available method if there is a choice but local policy may dictate that a weaker method is to be used If the client qop or server qop received by the server or client does not match the server qops or client qops bitmask the semantic is that the indicated i e through client qop or server qop quality of protection is required by the other end to complete the authentication The entity receiving such a message may decide using local policy whether to continue authentication or not Normally the authentication is aborted because the other end did not meet the supported preferred quality of protections announced by the local end but in some cases accepting the other ends decision may be acceptable Note that the quality of protection fields are both integrity and privacy protected thus protecting this negotiation If the protocol support initial data from the client and the PROT READY flag is set in the client after the first call to GSS Init sec context and the server can send additional data to the client when indicating successful authentication the following protocol exchange will occur C Request authentication exchange and send length GSS Init sec context GSS Wrap client qops client maxbuf authzid token S Indicate successful authentication and send length GSS Accept sec context GSS Wrap server qop server maxbuf token as additional information The last example illustrate the optimal round trip wise authentication possible using this protocol 4 3 GSS API parameters The implementation MAY set any GSSAPI flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy 4 4 Security layer bits The security layers and their corresponding bit masks are as follows 1 No security layer 2 Integrity protection Sender calls GSS Wrap with conf flag set to FALSE 4 Confidentiality protection Sender calls GSS Wrap with conf flag set to TRUE Other bit masks may be defined in the future bits which are not Josefsson Expires May 21 2006 Page 9 Internet Draft SASL GS2 November 2005 understood must be negotiated off Note that SASL negotiates the maximum size of the output message to send Implementations can use the GSS Wrap size limit call to determine the corresponding maximum size input message 4 5 Authorization identity format The authorization identity is encoded using UTF 8 6 The authorization identity is not terminated with the NUL U 0000 character 4 6 Client side of authentication protocol exchange The client calls GSS Init sec context passing in input context handle of 0 initially mech type of the GSSAPI mechanism for which this SASL mechanism is registered any chan binding if requested by the application and targ name equal to output name from GSS Import Name called with input name type of GSS C NT HOSTBASED SERVICE and input name string of service hostname where service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server If the client will be requesting a security layer it MUST also supply to the GSS Init sec context a mutual req flag of TRUE a sequence req flag of TRUE and an integ req flag of TRUE If the client will be requesting a security layer providing confidentiality protection it MUST also supply to the GSS Init sec context a conf req flag of TRUE The client then send a four octet network byte order integer encoding the length of the resulting output token concatenated with the actual token If GSS Init sec context returns GSS S CONTINUE NEEDED then the client should expect the server to issue a token in a subsequent challenge or as additional information to the outcome of the authentication The token received from the server will be prefixed with a four octet network byte order integer encoding the length of the context token The client must pass the context token to another call to GSS Init sec context repeating the actions in this paragraph until GSS S COMPLETE is returned or authentication is aborted If the server supply data beyond the context token the context token should be processed first and then the overflow data should be passed to GSS Unwrap and the unwrapped data should be interpreted as described below When GSS Init sec context returns GSS S COMPLETE the client examines the context to ensure that it provides a level of protection permitted by the client s security policy If the context is unacceptable the client abort the authentication Otherwise if the last call to GSS Init sec context returned an output token that Josefsson Expires May 21 2006 Page 10 Internet Draft SASL GS2 November 2005 token is returned to the server prefixed with the length integer together with a GSS Wrap token unless the client already sent the GSS Wrap token earlier If the call to GSS Init sec context did not return any additional token in output token it will respond with an empty context token i e a length field value of 0 and a GSS Wrap token unless the client already sent the GSS Wrap token earlier When the context has been established or if the PROT READY flag is set by the call to GSS Init sec context the client may send in addition to the length field and output token if any a GSS Wrap token The client passes data to GSS Wrap with conf flag set to FALSE and responds with the generated output message If the client has not received a GSS Wrap token from the server yet the data will contain one octet with a bit mask indicating the client s supported preferred security layer client qops then three octets encoding in network byte order an integer indicating the maximum message size client maxbuf that the client can receive set to 0 if no integrity or privacy layer is requested and the remaining data is the UTF 8 6 encoded authorization identity authzid which may be empty The client will later expect a GSS Wrap token from the server The client passes this token to GSS Unwrap and interprets the first octet of resulting cleartext as the selected security layer server qop and the second through fourth octets as the network byte order maximum size output message to send to the server server maxbuf The client will verify that the selected security layer is acceptable it may be different from what was requested in client qops If the client has received a GSS Wrap token from the server earlier the client passes that token to GSS Unwrap and interprets the first octet of resulting cleartext as a bit mask indicating the supported preferred security layer that the server wish to use server qops and the second through fourth octets as the network byte order integer indicating the maximum size output message to send to the server server maxbuf The client then proceed to create the data used as input to GSS Wrap The data will contain one octet indicating the selected quality of protection level client qop which should be one of those indicated in the bit mask received from the server but may be different if the client would abort authentication here and want to give the server a chance to use a different security method three octets encoding in network byte order an integer indicating the maximum buffer size client maxbuf that the client can receive set to 0 if no integrity or privacy layer is requested and the remaining octets containing the UTF 8 6 encoded authorization identity authzid which may be empty Josefsson Expires May 21 2006 Page 11 Internet Draft SASL GS2 November 2005 The client must validate the GSS Wrap token it receive from the server If the resulting cleartext received from GSS Unwrap is not 4 octets long the client fails the negotiation The client verifies that the server maximum buffer is 0 if the server doesn t advertise support for any security layer 4 7 Server side of authentication protocol exchange The server passes the first client response to GSS Accept sec context as input token setting input context handle to 0 initially mech type of the GSSAPI mechanism for which this SASL mechanism is registered any chan binding if requested by the application and acceptor cred handle equal to output cred handle from GSS Acquire cred called with desired name equal to output name from GSS Import name with input name type of GSS C NT HOSTBASED SERVICE and input name string of service hostname where service is the service name specified in the protocol s profile and hostname is the fully qualified host name of the server If GSS Accept sec context returns GSS S CONTINUE NEEDED the server send to the client the challenge consisting of a four octet network byte order integer encoding the length of the resulting output token concatenated with the actual token The server must pass the resulting challenge from the client to another call to GSS Accept sec context repeating the actions in this paragraph until GSS S COMPLETE is returned or authentication is aborted If the client supply data beyond the context token the context token should be processed first and then the overflow data should be passed to GSS Unwrap and the unwrapped data should be interpreted as described below When GSS Accept sec context returns GSS S COMPLETE the server examines the context to ensure that it provides a level of protection permitted by the server s security policy If the context is unacceptable the server abort the authentication Otherwise if the last call to GSS Accept sec context returned an output token the server returns it to the client in a challenge prefixed with the length integer together with a GSS Wrap token unless the server already sent the GSS Wrap token earlier If the GSS Accept sec context did not return an output token the server return an empty context i e length 0 together with a GSS Wrap token unless the server already sent the GSS Wrap token earlier When the context has been established or if the PROT READY flag is set by the call to GSS Accept sec context the server may send in addition to the length field and output token if any a GSS Wrap token The server passes data to GSS Wrap with conf flag set to FALSE and responds with the generated output message Josefsson Expires May 21 2006 Page 12 Internet Draft SASL GS2 November 2005 If the server has not received a GSS Wrap token from the client yet the data will contain one octet with a bit mask indicating the server s supported preferred security layer server qops then three octets encoding in network byte order an integer indicating the maximum message size server maxbuf that the server can receive set to 0 if no integrity or privacy layer is requested The server will later expect a GSS Wrap token from the client The server pass this token to GSS Unwrap and interprets the first octet of resulting cleartext as the selected security layer client qop and the second through fourth octets as the network byte order maximum size output message to send to the client client maxbuf The server will verify that the selected security layer is acceptable it may be different from what indicated in server qops If the server has received a GSS Wrap token from the client earlier the server passes that token to GSS Unwrap and interprets the first octet of resulting cleartext as a bit mask indicating the client s supported preferred security layer client qops and the second through fourth octets as the network byte order integer indicating the maximum size output message to send to the client client maxbuf The server then proceed to create the data used as input to GSS Wrap The data will contain one octet indicating the selected security layer server qop which should be one of those indicated in the bit mask received from the client but may be different if the server would abort authentication here and want to give the client a chance to use a different security method three octets encoding in network byte order an integer indicating the maximum buffer size server maxbuf that the server can receive set to 0 if no integrity or privacy layer is requested and the remaining octets containing the UTF 8 6 encoded authorization identity authzid which may be empty The server must verify that the src name identity is authorized to authenticate as the authorization identity After these verifications the authentication process is complete The server must validate the GSS Wrap token it receive from the client If the resulting cleartext received from GSS Unwrap is shorter than 4 octets the server fails the negotiation The server verifies that the server maximum buffer is 0 if the server doesn t advertise support for any security layer 5 SPNEGO Use of The Simple and Protected GSS API Negotiation Mechanism 10 SPNEGO underneath SASL introduces subtle interoperability problems and security considerations To address these this section places additional requirements on implementations which support SPNEGO Josefsson Expires May 21 2006 Page 13 Internet Draft SASL GS2 November 2005 underneath SASL A client which supports for example the Kerberos V5 GSSAPI mechanism only underneath SPNEGO underneath the GSS SPNEGO SASL mechanism will not interoperate with a server which supports the Kerberos V5 GSSAPI mechanism only underneath the GSSAPI SASL mechanism A client that only support

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


  • the extension bitmask the KDC MUST return 4 octets with the high bit set and with the remaining bitmask indicating which extensions it supports The KDC then MUST wait and the client MUST send a second 4 octet value with the high bit set If the second 4 octet value is a PROBE or an unsupported extension the KDC MUST close the connection This can be used by the client to shutdown a session when the KDC did not support a by the client required extension If the second 4 octet value is a supported extension the KDC MUST respond by sending a 4 octet zero value i e 0x00000000 The KDC MAY directly send additional data after the zero value as specified by the particular negotiated extension The client and KDC SHOULD wait for the other side to respond according to this protocol and the client and KDC SHOULD NOT close the connection prematurely Resource availability considerations may influence whether and for how long the client and KDC will wait for the other side to respond to a request The KDC MUST NOT support the extension mechanism if it does not support any extensions If no extensions are supported the KDC MUST return a KRB ERROR message with the error KRB ERR FIELD TOOLONG and MUST close the TCP stream similar to what an implementation that does not understand this extension mechanism would do The behaviour when more than one non high bit is set depends on the particular extension mechanisms If a requested extension bit X does not specify how it interacts with another requested extension bit Y the KDC MUST treat the request as a PROBE or unsupported extension and proceed as above Each extension MUST describe the structure of protocol data beyond the length field and the behaviour of the client and KDC In particular the structure may be a protocol with its own message framing If an extension mechanism reserves multiple bits it MUST describe how they interact 4 Interoperability Consideration Implementations with support for TCP that do not claim to conform to RFC 4120 may not handle the high bit correctly The KDC behaviour may include closing the TCP connection without any response and logging an error message in the KDC log When this was written this Josefsson Expires November 2 2007 Page 4 Internet Draft Kerberos V5 TCP extension May 2007 problem existed in modern versions of popular KDC implementations Implementations experiencing trouble getting the expected responses from a KDC might assume that the KDC does not support this extension mechanism A client might remember this semi permanently to avoid triggering the same problematic behaviour on the KDC every time Care should be taken to avoid unexpected behaviour for the user when the KDC is eventually upgraded Implementations might also provide a way to enable and disable this extension on a per realm basis How to handle these backwards compatibility quirks are in general left unspecified 5 Security Considerations Because the initial length

    Original URL path: http://www.josefsson.org/krb5starttls/draft-ietf-krb-wg-tcp-expansion.txt (2016-04-30)
    Open archived version from archive


  • the extension by setting the STARTTLS bit in the TCP extension mechanism bitmask How to deal with extension negotiation failures at this point is described in RFC5021 After the server has sent the 4 octet value 0x00000000 to indicate support of this extension the stream will be controlled by the TLS protocol and its framing The TLS protocol is initiated by the client Typically the client initiate the TLS handshake protocol by sending a client hello and the server responds and the handshake continues until it either succeed or fails If for any reason the handshake fails the STARTTLS protocol will also fail and the TLS error is used as the error indication In this case no further messages can be exchanged over the same TCP session If the handshake succeeds the Kerberos V5 authentication protocol is performed within the protected TLS channel like a normal TCP Kerberos V5 exchange In particular this means that every Kerberos V5 packet will be prefixed by a 4 octet length field that indicate the length of the Kerberos V5 packet When no further Kerberos V5 messages needs to be transferred in the TLS session the TLS session MUST be shut down properly using the close notify alert When the TLS session is shut down the TCP connection cannot be re used to send any further data and MUST be closed Josefsson Expires February 15 2011 Page 4 Internet Draft Protecting Kerberos V5 with TLS August 2010 3 Examples A complete packet flow for a successful AS REQ REP exchange protected by this mechanism will be as follows The STARTTLS bit is a 4 octet value with only the bit allocated for this extension set and is the binary OR operation Client Server Kerberos V5 TCP extension mechanism negotiation starts 0x80000000 STARTTLS bit 0x00000000 ServerHello Certificate ServerKeyExchange CertificateRequest ChangeCipherSpec 4 octet length field Kerberos V5 AS REP Indicates optional or situation dependent messages that are not always sent Josefsson Expires February 15 2011 Page 5 Internet Draft Protecting Kerberos V5 with TLS August 2010 4 STARTTLS aware KDC Discovery Section 7 2 3 of Kerberos V5 RFC4120 describe how Domain Name System DNS SRV records RFC2782 can be used to find the address of an KDC We define a new Service of kerberos tls to indicate that the particular KDC is intended to support this STARTTLS extension The Proto tcp Realm TTL Class SRV Priority Weight Port and Target have the same meaning as in RFC 4120 For example kerberos tls tcp EXAMPLE COM IN SRV 0 0 88 kdc1 example com kerberos tls tcp EXAMPLE COM IN SRV 1 0 88 kdc2 example com Josefsson Expires February 15 2011 Page 6 Internet Draft Protecting Kerberos V5 with TLS August 2010 5 Server Certificates The TLS protocol may be used in a mode that provides server authentication using for example X 509 and OpenPGP A goal for the protocol described in this memo is that it should be as easy to implement and deploy

    Original URL path: http://www.josefsson.org/krb5starttls/draft-josefsson-kerberos5-starttls.txt (2016-04-30)
    Open archived version from archive

  • Using Kerberos V5 over the Transport Layer Security (TLS) protocol
    KDC Exchanges over TCP August 2007 RFC5021 The extension uses bit TBD in the extension bitmask The protocol is as follows The client requests the extension by setting the STARTTLS bit in the TCP extension mechanism bitmask How to deal with extension negotiation failures at this point is described in RFC5021 Josefsson S Extended Kerberos Version 5 Key Distribution Center KDC Exchanges over TCP August 2007 After the server has sent the 4 octet value 0x00000000 to indicate support of this extension the stream will be controlled by the TLS protocol and its framing The TLS protocol is initiated by the client Typically the client initiate the TLS handshake protocol by sending a client hello and the server responds and the handshake continues until it either succeed or fails If for any reason the handshake fails the STARTTLS protocol will also fail and the TLS error is used as the error indication In this case no further messages can be exchanged over the same TCP session If the handshake succeeds the Kerberos V5 authentication protocol is performed within the protected TLS channel like a normal TCP Kerberos V5 exchange In particular this means that every Kerberos V5 packet will be prefixed by a 4 octet length field that indicate the length of the Kerberos V5 packet When no further Kerberos V5 messages needs to be transferred in the TLS session the TLS session MUST be shut down properly using the close notify alert When the TLS session is shut down the TCP connection cannot be re used to send any further data and MUST be closed TOC 3 Examples A complete packet flow for a successful AS REQ REP exchange protected by this mechanism will be as follows The STARTTLS bit is a 4 octet value with only the bit allocated for this extension set and is the binary OR operation Client Server Kerberos V5 TCP extension mechanism negotiation starts 0x80000000 STARTTLS bit 0x00000000 TLS negotiation starts ClientHello ServerHello Certificate ServerKeyExchange CertificateRequest ServerHelloDone Certificate ClientKeyExchange CertificateVerify ChangeCipherSpec Finished ChangeCipherSpec Finished Kerberos V5 negotiation starts 4 octet length field Kerberos V5 AS REQ 4 octet length field Kerberos V5 AS REP Indicates optional or situation dependent messages that are not always sent TOC 4 STARTTLS aware KDC Discovery Section 7 2 3 of Kerberos V5 Neuman C Yu T Hartman S and K Raeburn The Kerberos Network Authentication Service V5 July 2005 RFC4120 describe how Domain Name System DNS SRV records Gulbrandsen A Vixie P and L Esibov A DNS RR for specifying the location of services DNS SRV February 2000 RFC2782 can be used to find the address of an KDC We define a new Service of kerberos tls to indicate that the particular KDC is intended to support this STARTTLS extension The Proto tcp Realm TTL Class SRV Priority Weight Port and Target have the same meaning as in RFC 4120 For example kerberos tls tcp EXAMPLE COM IN SRV 0 0 88 kdc1 example com kerberos tls tcp

    Original URL path: http://www.josefsson.org/krb5starttls/draft-josefsson-kerberos5-starttls.html (2016-04-30)
    Open archived version from archive

  • Diff: draft-josefsson-kerberos5-starttls-08.txt - draft-josefsson-kerberos5-starttls.txt
    Process and derivative works of it may outside the IETF Standards Process and derivative works of it may not be created outside the IETF Standards Process except to format not be created outside the IETF Standards Process except to format skipping to change at page 7 line 9 skipping to change at page 6 line 9 Kerberos V5 AS REP Kerberos V5 AS REP Indicates optional or situation dependent messages that are not Indicates optional or situation dependent messages that are not always sent always sent 4 STARTTLS aware KDC Discovery 4 STARTTLS aware KDC Discovery Section 7 2 3 of Kerberos V5 RFC4120 describe how Domain Name Section 7 2 3 of Kerberos V5 RFC4120 describe how Domain Name System DNS SRV records RFC2782 can be used to find the address of System DNS SRV records RFC2782 can be used to find the address of an KDC We define a new Proto of tls to indicate that the an KDC We define a new Service of kerberos tls to indicate that particular KDC is intended to support this STARTTLS extension The the particular KDC is intended to support this STARTTLS extension Service Realm TTL Class SRV Priority Weight Port and Target The Proto tcp Realm TTL Class SRV Priority Weight Port and have the same meaning as in RFC 4120 Target have the same meaning as in RFC 4120 For example For example kerberos tls EXAMPLE COM IN SRV 0 0 88 kdc1 example com kerberos tls tcp EXAMPLE COM IN SRV 0 0 88 kdc1 example com kerberos tls EXAMPLE COM IN SRV 1 0 88 kdc2 example com kerberos tls tcp EXAMPLE COM IN SRV 1 0 88 kdc2 example com 5 Server Certificates 5 Server Certificates The TLS protocol may be used in a mode that provides server The TLS protocol may be used in a mode that provides server authentication using for example X 509 and OpenPGP authentication using for example X 509 and OpenPGP The Kerberos V5 STARTTLS protocol do not require clients to verify A goal for the protocol described in this memo is that it should be the server certificate The goal is that support for TLS in Kerberos as easy to implement and deploy on clients as support for UDP TCP V5 clients should be as easy to implement and deploy as support for Since many client environments do not have access to long term UDP TCP Use of TLS even without server certificate validation storage or to long term storage that is sufficiently secure to protects against some attacks that Kerberos V5 over UDP TCP do not enable validation of server certificates the Kerberos V5 STARTTLS For example passive network sniffing between the user and the KDC protocol does not require clients to verify server certificates If to track which Kerberos services are used by the user To require server certification had been required then environments with server certificates to be validated at all times would lead to constrained clients

    Original URL path: http://www.josefsson.org/krb5starttls/draft-josefsson-kerberos5-starttls-from--08.diff.html (2016-04-30)
    Open archived version from archive

  • Diff: draft-josefsson-kerberos5-starttls-07.txt - draft-josefsson-kerberos5-starttls-08.txt
    several reasons to use Kerberos V5 over TLS o Prevents downgrade attacks affecting e g encryption types and o Prevents downgrade attacks affecting e g encryption types and pre auth data negotiation The encryption type field in KDC REQ pre auth data negotiation The encryption type field in KDC REQ and the METHOD DATA field with the requested pre auth types from and the METHOD DATA field with the requested pre auth types from the server in KDC ERR PREAUTH REQUIRED errors in KDC REP are sent the server in KDC ERR PREAUTH REQUIRED errors in KDC REP are sent without integrity or privacy protection in Kerberos 5 This without integrity or privacy protection in Kerberos 5 This allows an active attacker to replace the encryption type with a allows an active attacker to replace the encryption type with a compromised encryption type e g 56 bit DES or request that compromised encryption type e g 56 bit DES or request that skipping to change at page 4 line 43 skipping to change at page 4 line 44 encryption That part contains information such as the client encryption That part contains information such as the client principal name the server principal name the encryption types principal name the server principal name the encryption types supported by the client the lifetime of tickets etc Revealing supported by the client the lifetime of tickets etc Revealing such information is in some threat models considered a problem such information is in some threat models considered a problem o Additional authentication against the KDC In some situations o Additional authentication against the KDC In some situations users are equipped with smart cards with a RSA authentication key users are equipped with smart cards with a RSA authentication key In others users have a OpenPGP client on their desktop with a In others users have a OpenPGP client on their desktop with a public OpenPGP key known to the server public OpenPGP key known to the server o The TLS protocol has been studied by many parties In some threat models the designer prefer to reduce the number of protocols that can hurt the overall system security if they are compromised o Explicit server authentication of the KDC to the client In o Explicit server authentication of the KDC to the client In traditional Kerberos 5 authentication of the KDC is proved as a traditional Kerberos 5 authentication of the KDC is proved as a side effect that the KDC knows your encryption key i e your side effect that the KDC knows your encryption key i e your password password The key words MUST MUST NOT REQUIRED SHALL SHALL NOT The key words MUST MUST NOT REQUIRED SHALL SHALL NOT SHOULD SHOULD NOT RECOMMENDED MAY and OPTIONAL in this SHOULD SHOULD NOT RECOMMENDED MAY and OPTIONAL in this document are to be interpreted as described in RFC 2119 RFC2119 document are to be interpreted as described in RFC 2119 RFC2119 2 Kerberos V5 STARTTLS Extension 2 Kerberos V5 STARTTLS Extension The STARTTLS extension uses the Kerberos V5 TCP extension mechanism The STARTTLS extension uses the Kerberos V5 TCP extension mechanism RFC5021 The extension uses bit TBD in the extension bitmask RFC5021 The extension uses bit TBD in the extension bitmask The protocol is as follows After the server has sent the 4 octet The protocol is as follows The client requests the extension by value 0x00000000 to indicate support of this extension the stream setting the STARTTLS bit in the TCP extension mechanism bitmask will be controlled by the TLS protocol and its framing The TLS How to deal with extension negotiation failures at this point is protocol is initiated by the client described in RFC5021 After the server has sent the 4 octet value 0x00000000 to indicate support of this extension the stream will be controlled by the TLS protocol and its framing The TLS protocol is initiated by the client Typically the client initiate the TLS handshake protocol by sending Typically the client initiate the TLS handshake protocol by sending a client hello and the server responds and the handshake continues a client hello and the server responds and the handshake continues until it either succeed or fails until it either succeed or fails If for any reason the handshake fails the STARTTLS protocol will If for any reason the handshake fails the STARTTLS protocol will also fail and the TLS error is used as the error indication In also fail and the TLS error is used as the error indication In this case no further messages can be exchanged over the same TCP this case no further messages can be exchanged over the same TCP session session skipping to change at page 7 line 9 skipping to change at page 6 line 9 When no further Kerberos V5 messages needs to be transferred in the When no further Kerberos V5 messages needs to be transferred in the TLS session the TLS session MUST be shut down properly using the TLS session the TLS session MUST be shut down properly using the close notify alert When the TLS session is shut down the TCP close notify alert When the TLS session is shut down the TCP connection cannot be re used to send any further data and MUST be connection cannot be re used to send any further data and MUST be closed closed 3 Examples 3 Examples A complete packet flow for a successful AS REQ REP exchange protected A complete packet flow for a successful AS REQ REP exchange protected by this mechanism will be as follows The STARTTLS bit is a by this mechanism will be as follows The STARTTLS bit is a 4 octet value with only the bit allocated for this extension set 4 octet value with only the bit allocated for this extension set and is the binary OR operation Client Server Client Server Kerberos V5 TCP extension mechanism negotiation starts Kerberos V5 TCP extension mechanism

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

  • Diff: draft-josefsson-kerberos5-starttls-06.txt - draft-josefsson-kerberos5-starttls-07.txt
    change at page 9 line 5 an KDC We define a new Proto of tls to indicate that the an KDC We define a new Proto of tls to indicate that the particular KDC is intended to support this STARTTLS extension The particular KDC is intended to support this STARTTLS extension The Service Realm TTL Class SRV Priority Weight Port and Target Service Realm TTL Class SRV Priority Weight Port and Target have the same meaning as in RFC 4120 have the same meaning as in RFC 4120 For example For example kerberos tls EXAMPLE COM IN SRV 0 0 88 kdc1 example com kerberos tls EXAMPLE COM IN SRV 0 0 88 kdc1 example com kerberos tls EXAMPLE COM IN SRV 1 0 88 kdc2 example com kerberos tls EXAMPLE COM IN SRV 1 0 88 kdc2 example com 5 Validation of Server Certificate 5 Server Certificates The TLS protocol can provide server authentication using for The TLS protocol may be used in a mode that provides server example X 509 and OpenPGP By validating the server certificate authentication using for example X 509 and OpenPGP clients can be certain that it is talking to the intended KDC The Kerberos V5 STARTTLS protocol do not require clients to verify The Kerberos V5 STARTTLS protocol do not require clients to verify the server certificate The goal is that support for TLS in Kerberos the server certificate The goal is that support for TLS in Kerberos V5 clients should be as easy to implement and deploy as support for V5 clients should be as easy to implement and deploy as support for UDP TCP Use of TLS even without server certificate validation UDP TCP Use of TLS even without server certificate validation protects against some attacks that Kerberos V5 over UDP TCP do not protects against some attacks that Kerberos V5 over UDP TCP do not Requiring server certificates to be used at all times would enable Requiring server certificates to be used at all times would enable attacks in those situations attacks in those situations Many clients does not have secure long term storage that is required Many client environments do not have secure long term storage which to validate certificates This makes it impossible to implement is required to validate certificates This makes it impossible to server certificate validation in practice on a large number of use server certificate validation on a large number of client deployed systems systems When clients have the ability they need to be able to validate the When clients have the ability they need to be able to validate the server certificate For this reason if a KDC presents a X 509 server certificate For this reason if a KDC presents a X 509 server certificate over TLS it MUST contain an otherName Subject server certificate over TLS it MUST contain an otherName Subject Alternative Name SAN identified using a type id of id krb5starttls Alternative Name SAN identified using a type id of

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



  •