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

  • broken pre auth type Since clients in general cannot know the encryption types other servers support or the pre auth types servers prefer or require it is difficult for the client to detect if there was a man in the middle or if the remote server simply did not support a stronger encryption type or preferred another pre auth type o Kerberos exchanges are privacy protected Part of many Kerberos packets are transfered without privacy protection i e encryption That part contains information such as the client principal name the server principal name the encryption types supported by the client the lifetime of tickets etc Revealing such information is in some threat models considered a problem o Additional authentication against the KDC In some situations users are equipped with smart cards with a RSA authentication key In others users have a OpenPGP client on their desktop with a 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 traditional Kerberos 5 authentication of the KDC is proved as a side effect that the KDC knows your encryption key i e your password The key words MUST MUST NOT REQUIRED SHALL SHALL NOT Josefsson Expires September 3 2009 Page 4 Internet Draft Protecting Kerberos V5 with TLS March 2009 SHOULD SHOULD NOT RECOMMENDED MAY and OPTIONAL in this document are to be interpreted as described in RFC 2119 RFC2119 Josefsson Expires September 3 2009 Page 5 Internet Draft Protecting Kerberos V5 with TLS March 2009 2 Kerberos V5 STARTTLS Extension The STARTTLS extension uses the Kerberos V5 TCP extension mechanism RFC5021 The extension uses bit TBD in the extension bitmask The protocol is as follows 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 However to conform with this specification any KDC REQ AS REQ or TGS REQ message MUST contain the pa channel binding pre authentication data When no further Kerberos V5 messages needs to be transferred

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



  • the Kerberos V5 TCP extension mechanism RFC5021 The extension uses bit TBD in the extension bitmask The protocol is as follows 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 However to conform with this specification any KDC REQ AS REQ or TGS REQ message MUST contain the pa channel binding pre authentication data 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 furhter data and MUST be closed Josefsson Expires June 8 2009 Page 5 Internet Draft Protecting Kerberos V5 with TLS December 2008 3 Channel Binding Pre Authentication Data The pre authentication structure is defined in RFC 4120 as PA DATA SEQUENCE NOTE first tag is 1 not 0 padata type 1 Int32 padata value 2 OCTET STRING might be encoded AP REQ Here we define a new pre authentication data called pa channel binding It has a padata type integer value of TBD The contents of the padata value field is the channel binding data as discussed in RFC5056 Josefsson Expires June 8 2009 Page 6 Internet Draft Protecting Kerberos V5 with TLS December 2008 4 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 Client Server Kerberos V5 TCP extension mechanism negotiation starts 0x70000000 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 June 8 2009 Page 7 Internet Draft Protecting Kerberos V5 with TLS December 2008 5 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 Proto of tls to indicate that the particular KDC is intended to support this STARTTLS extension The Service Realm

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


  • The key words MUST MUST NOT REQUIRED SHALL SHALL NOT SHOULD SHOULD NOT RECOMMENDED MAY and OPTIONAL in this document are to be interpreted as described in RFC 2119 1 Josefsson Expires June 5 2008 Page 4 Internet Draft Protecting Kerberos V5 with TLS December 2007 2 Kerberos V5 STARTTLS Extension The STARTTLS extension uses the Kerberos V5 TCP extension mechanism 5 The extension uses bit TBD in the extension bitmask The protocol is as follows 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 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 However to conform with this specification any KDC REQ AS REQ or TGS REQ message MUST contain the pa channel binding pre authentication data Josefsson Expires June 5 2008 Page 5 Internet Draft Protecting Kerberos V5 with TLS December 2007 3 Channel Binding Pre Authentication Data The pre authentication structure is defined in RFC 4120 as PA DATA SEQUENCE NOTE first tag is 1 not 0 padata type 1 Int32 padata value 2 OCTET STRING might be encoded AP REQ Here we define a new pre authentication data called pa channel binding It has a padata type integer value of TBD The contents of the padata value field is the channel binding data as discussed in 6 Josefsson Expires June 5 2008 Page 6 Internet Draft Protecting Kerberos V5 with TLS December 2007 4 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 Client Server Kerberos V5 TCP extension mechanism negotiation starts 0x70000000 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 June 5 2008 Page 7 Internet Draft Protecting Kerberos V5 with TLS December 2007 5 STARTTLS aware KDC Discovery Section 7 2 3 of Kerberos V5 3 describe how Domain Name System DNS SRV records 2 can be used to find the address of an KDC Using the terminology of Section 7 2 3 of RFC 4120 we define a new Proto of tls to indicate that the particular KDC is intended to support this STARTTLS extension The

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


  • return 4 octets with the high bit set and with the remaining bitmask indicate 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 avaibility 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 interact with another requested extensions 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 reserve 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 problem existed in modern versions of popular KDC implementations Josefsson Expires November 3 2007 Page 4 Internet Draft Kerberos V5 TCP extension May 2007 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 field is not protected it is

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


  • can hurt the overall system security if they are compromised o Explicit server authentication of the KDC to the client In traditional Kerberos 5 authentication of the KDC is proved as a side effect that the KDC knows your encryption key i e your Josefsson Expires April 24 2007 Page 3 Internet Draft Protecting Kerberos V5 with TLS October 2006 password The key words MUST MUST NOT REQUIRED SHALL SHALL NOT SHOULD SHOULD NOT RECOMMENDED MAY and OPTIONAL in this document are to be interpreted as described in RFC 2119 1 Josefsson Expires April 24 2007 Page 4 Internet Draft Protecting Kerberos V5 with TLS October 2006 2 Kerberos V5 STARTTLS Extension The STARTTLS extension uses the Kerberos V5 TCP extension mechanism 3 The extension uses bit TBD in the extension bitmask The protocol is as follows 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 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 Josefsson Expires April 24 2007 Page 5 Internet Draft Protecting Kerberos V5 with TLS October 2006 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 Client Server Kerberos V5 TCP extension mechanism negotiation starts 0x70000000 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 April 24 2007 Page 6 Internet Draft Protecting Kerberos V5 with TLS October 2006 4 STARTTLS aware KDC Discovery Section 7 2 3 of Kerberos V5 2 describe how Domain Name System DNS SRV records 5 can be used to find the address of an KDC Using the terminology of Section 7 2 3 of RFC 4120 we define a new Proto of tls to indicate that the particular KDC is intended to support this STARTTLS extension The Service Realm TTL Class SRV Priority Weight Port and Target have the same meaning as in RFC 4120 For example kerberos tls EXAMPLE COM IN SRV 0 0 88 kdc1 example com kerberos tls EXAMPLE COM IN SRV 1 0 88 kdc2 example com Josefsson Expires April 24 2007 Page 7 Internet Draft Protecting Kerberos V5

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


  • compromised o Explicit server authentication of the KDC to the client In traditional Kerberos 5 authentication of the KDC is proved as a side effect that the KDC knows your encryption key i e your Josefsson Expires April 7 2007 Page 3 Internet Draft Protecting Kerberos V5 with TLS October 2006 password The key words MUST MUST NOT REQUIRED SHALL SHALL NOT SHOULD SHOULD NOT RECOMMENDED MAY and OPTIONAL in this document are to be interpreted as described in RFC 2119 1 Josefsson Expires April 7 2007 Page 4 Internet Draft Protecting Kerberos V5 with TLS October 2006 2 Kerberos V5 STARTTLS Extension The STARTTLS extension uses the Kerberos V5 TCP extension mechanism 3 The extension uses bit TBD in the extension bitmask The protocol is as follows 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 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 Josefsson Expires April 7 2007 Page 5 Internet Draft Protecting Kerberos V5 with TLS October 2006 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 Client Server Kerberos V5 TCP extension mechanism negotiation starts 0x70000000 STARTTLS bit 0x00000000 ServerHello Certificate ServerKeyExchange CertificateRequest ChangeCipherSpec Kerberos V5 AS REP Indicates optional or situation dependent messages that are not always sent Josefsson Expires April 7 2007 Page 6 Internet Draft Protecting Kerberos V5 with TLS October 2006 4 STARTTLS aware KDC Discovery Section 7 2 3 of Kerberos V5 2 describe how Domain Name System DNS SRV records 5 can be used to find the address of an KDC Using the terminology of Section 7 2 3 of RFC 4120 we define a new Proto of tls to indicate that the particular KDC is intended to support this STARTTLS extension The Service Realm TTL Class SRV Priority Weight Port and Target have the same meaning as in RFC 4120 For example kerberos tls EXAMPLE COM IN SRV 0 0 88 kdc1 example com kerberos tls EXAMPLE COM IN SRV 1 0 88 kdc2 example com Josefsson Expires April 7 2007 Page 7 Internet Draft Protecting Kerberos V5 with TLS October 2006 5 IANA Considerations The IANA is requested to allocate

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


  • zero size If a KDC receive a PROBE or if a KDC does not support all extensions corresponding to set bits in the extension bitmask the KDC MUST return 4 octets with the high bit set and with the remaining bitmask indicate 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 avaibility 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 interact with another requested extensions 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 reserve 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 problem existed in modern versions of popular KDC implementations Josefsson Expires March 17 2007 Page 4 Internet Draft Kerberos V5 TCP extension September 2006 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

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


  • the KDC MUST return 4 octets with the high bit set and with the remaining bitmask indicate which extensions it supports The KDC SHOULD NOT close the connection and SHOULD wait for the client to then send a second 4 octet value with the high bit set and the remaining bits as the bitmask to request a particular extension If the second 4 octet value is a PROBE or an unsupported extension the KDC MUST close the connection This is used by the client to shutdown a session when the KDC did not support a by the client required extension Resource avaibility considerations may influence whether and for how long the KDC will wait for the client to send requests The behaviour when more than one non high bit is set depends on the Josefsson Expires November 11 2006 Page 3 Internet Draft Kerberos V5 TCP extension May 2006 particular extension mechanisms If a requested extension bit X does not specify how it interact with another requested extensions 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 If an extension mechanism reserve 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 Behaviour may include closing the TCP connection without any response and logging an error message in the KDC log When this was written this problem existed in modern versions of popular implementations Implementations experiencing trouble getting the expected responses from a server SHOULD assume that it does not support this extension mechanism Clients MAY remember this semi permanently to avoid excessive logging in the server Care should be taken to avoid unexpected behaviour for the user when the KDC is eventually upgraded Implementations MAY 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 field is not protected it is possible for an active attacker i e one that is able to modify traffic between the client and the KDC to make it appear to the client that the server does not support this extension mechanism Client and KDC policies can be used to reject connections that does not use any expansion 6 IANA Considerations IANA needs to create a new registry for Kerberos 5 TCP Extensions The initial contents of this registry should be RFC Editor Replace xxxx below with the number of this RFC Bit Meaning Reference 0 29 AVAILABLE for registration Josefsson Expires November 11 2006 Page 4 Internet Draft Kerberos V5 TCP extension May 2006 30 RESERVED RFC XXXX IANA will register values 0 to 29 after IESG Approval as defined in BCP 64 2 Assigning value 30

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



  •