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-josefsson-kerberos5-starttls-05.txt - draft-josefsson-kerberos5-starttls-06.txt
    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 skipping to change at page 6 line 28 skipping to change at page 6 line 28 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 If the handshake succeeds the Kerberos V5 authentication protocol is If the handshake succeeds the Kerberos V5 authentication protocol is performed within the protected TLS channel like a normal TCP performed within the protected TLS channel like a normal TCP Kerberos V5 exchange In particular this means that every Kerberos Kerberos V5 exchange In particular this means that every Kerberos V5 packet will be prefixed by a 4 octet length field that indicate 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 the length of the Kerberos V5 packet 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 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 fur ht er data and MUST be connection cannot be re used to send any fur th er 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

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


  • Diff: draft-josefsson-kerberos5-starttls-04.txt - draft-josefsson-kerberos5-starttls-05.txt
    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 furhter data and MUST be connection cannot be re used to send any furhter data and MUST be closed closed 3 Channel Binding Pre Authentication Data 3 Examples 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 4 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 Client Server Client Server Kerberos V5 TCP extension mechanism negotiation starts Kerberos V5 TCP extension mechanism negotiation starts 0x70000000 STARTTLS bit 0x70000000 STARTTLS bit skipping to change at page 8 line 5 skipping to change at page 8 line 5 4 octet length field 4 octet length field Kerberos V5 AS REQ Kerberos V5 AS REQ 4 octet length field 4 octet length field 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 5 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 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

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

  • Diff: draft-josefsson-kerberos5-starttls-03.txt - draft-josefsson-kerberos5-starttls-04.txt
    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 1 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 5 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 After the server has sent the 4 octet value 0x00000000 to indicate support of this extension the stream value 0x00000000 to indicate support of this extension the stream will be controlled by the TLS protocol and its framing The TLS will be controlled by the TLS protocol and its framing The TLS protocol is initiated by the client 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 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 If the handshake succeeds the Kerberos V5 authentication protocol is performed within the protected TLS channel like a normal TCP performed within the protected TLS channel like a normal TCP Kerberos V5 exchange In particular this means that every Kerberos Kerberos V5 exchange In particular this means that every Kerberos V5 packet will be prefixed by a 4 octet length field that indicate 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 the length of the Kerberos V5 packet However to conform with this specification any KDC REQ AS REQ or TGS REQ message MUST contain specification any KDC REQ AS REQ or TGS REQ message MUST contain the pa channel binding pre authentication data 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 3 Channel Binding Pre Authentication Data 3 Channel Binding Pre Authentication Data The pre authentication structure is defined in RFC 4120 as The pre authentication structure is defined in RFC 4120 as PA DATA SEQUENCE PA DATA SEQUENCE NOTE first tag is 1 not 0 NOTE first tag is 1 not 0 padata type 1 Int32 padata type 1 Int32 padata value 2 OCTET STRING might be encoded AP REQ padata value 2 OCTET STRING might be encoded AP REQ Here we define a new pre authentication data called pa channel Here we define a new pre authentication data called pa channel binding It has a padata type integer value of TBD The contents binding It has a padata type integer value of TBD The contents of the padata value field is the channel binding data as discussed of the padata value field is the channel binding data as discussed in 6 in RFC505 6 4 Examples 4 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 Client Server Client Server Kerberos V5 TCP extension mechanism negotiation starts Kerberos V5 TCP extension mechanism negotiation starts skipping to change at page 8 line 7 skipping to change at page 8 line 7 Kerberos V5 AS REQ Kerberos V5 AS REQ 4 octet length field 4 octet length field 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 5 STARTTLS aware KDC Discovery 5 STARTTLS aware KDC Discovery Section 7 2 3 of Kerberos V5 3 describe how Domain Name System Section 7 2 3 of Kerberos V5 RFC4120 describe how Domain Name DNS SRV records 2 can be used to find the address of an KDC System DNS SRV records RFC2782 can be used to find the address of Using the terminology of Section 7 2 3 of RFC 4120 we define a new an KDC We define a new Proto of tls to indicate that the Proto of tls to indicate that the particular KDC is intended to particular KDC is intended to support this STARTTLS extension The support this STARTTLS extension The Service Realm TTL Class Service Realm TTL Class SRV Priority Weight Port and Target SRV Priority Weight Port and Target have the same meaning as in have the same meaning as in RFC 4120 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

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

  • Diff: draft-josefsson-kerberos5-starttls-02.txt - draft-josefsson-kerberos5-starttls-03.txt
    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 also fail and the TLS error is used as the error indication If the handshake succeeds the Kerberos V5 authentication protocol is If the handshake succeeds the Kerberos V5 authentication protocol is performed within the protected TLS channel like a normal TCP performed within the protected TLS channel like a normal TCP Kerberos V5 exchange In particular this means that every Kerberos Kerberos V5 exchange In particular this means that every Kerberos V5 packet will be prefixed by a 4 octet length field that indicate V5 packet will be prefixed by a 4 octet length field that indicate the length of the Kerberos V5 packet 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 3 Examples 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 4 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 Client Server Client Server Kerberos V5 TCP extension mechanism negotiation starts Kerberos V5 TCP extension mechanism negotiation starts 0x70000000 STARTTLS bit 0x70000000 STARTTLS bit skipping to change at page 7 line 5 skipping to change at page 8 line 5 4 octet length field 4 octet length field Kerberos V5 AS REQ Kerberos V5 AS REQ 4 octet length field 4 octet length field 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 5 STARTTLS aware KDC Discovery Section 7 2 3 of Kerberos V5 2 describe how Domain Name System Section 7 2 3 of Kerberos V5

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

  • Diff: draft-josefsson-kerberos5-starttls-01.txt - draft-josefsson-kerberos5-starttls-02.txt
    the Transport Layer Security TLS protocol to provide over the Transport Layer Security TLS protocol to provide additional security features additional security features skipping to change at page 3 line 17 skipping to change at page 3 line 17 This document describe how a Kerberos V5 2 implementation may This document describe how a Kerberos V5 2 implementation may upgrade communication between clients and Key Distribution Centers upgrade communication between clients and Key Distribution Centers KDCs to use the Transport Layer Security TLS 4 protocol KDCs to use the Transport Layer Security TLS 4 protocol The TLS protocol offer integrity and privacy protected exchanges that The TLS protocol offer integrity and privacy protected exchanges that can be authentication using X 509 certificates OpenPGP keys 7 and can be authentication using X 509 certificates OpenPGP keys 7 and user name and passwords via SRP 6 user name and passwords via SRP 6 There are several reasons to use Kerberos V5 over TLS There are several reasons to use Kerberos V5 over TLS o Prevents downgrade attacks affecting e g encryption types and pre auth data negotiation The encryption type field in KDC REQ 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 without integrity or privacy protection in Kerberos 5 This allows an attacker to replace the encryption type with a compromised encryption type e g 56 bit DES or request that clients should use a 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 o Kerberos exchanges are privacy protected Part of many Kerberos packets are transfered without privacy protection i e packets are transfered without privacy protection i e 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 Prevents downgrade attacks affecting encryption types The encryption type of the ticket in KDC REQ are sent in the clear in Kerberos 5 This allows an attacker to replace the encryption type with a compromised mechanisms e g 56 bit DES Since clients in general cannot know the encryption types other servers support it is difficult for the client to detect if there was a man in the middle or if the remote server simply did

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

  • Diff: draft-josefsson-kerberos5-starttls-00.txt - draft-josefsson-kerberos5-starttls-01.txt
    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 4 document are to be interpreted as described in RFC 2119 1 2 Extension Mechanism for TCP IP transport 2 Kerberos V5 STARTTLS Extension Kerberos 5 require Key Distribution Centers KDCs to accept requests The STARTTLS extension uses the Kerberos V5 TCP extension mechanism over TCP Each request and response is prefixed by 4 octets 3 The extension uses bit TBD in the extension bitmask encoding an integer in network byte order that indicate the length of the packet The high bit of the 4 octet length field was reserved for future expansion Servers that do not understand how to interpret a set high bit are required to return a KRB ERROR with the KRB ERR FIELD TOOLONG error code and to close the TCP stream We will use the reserved bit to provide an extension mechanism When The protocol is as follows After the server has sent the 4 octet the reserved high bit is set the remaining 31 bits of the 4 octets value 0x00000000 to indicate support of this extension the stream are treated as an extensible typed hole and thus form a 31 bit will be controlled by the TLS protocol and its framing The TLS integer enumerating various extensions Each of the values indicate protocol is initiated by the client a specific extended operation mode two of which are used and defined here and the rest are left for others to use If the KDC do not understand a requested extension it MUST return a Typically the client initiate the TLS handshake protocol by sending KRB ERROR with a KRB ERR FIELD TOOLONG value prefixed by the 4 octet a client hello and the server responds and the handshake continues length integer with the high bit clear as usual and close the TCP until it either succeed or fails stream The following table specify the meaning of the 31 lower bits in the 4 If for any reason the handshake fails the STARTTLS protocol will octet field when the high bit is set also fail and the TLS error is used as the error indication 0 RESERVED If the handshake succeeds the Kerberos V5 authentication protocol is 1 STARTTLS requested by client performed within the protected TLS channel like a normal TCP 2 STARTTLS request accepted by server Kerberos V5 exchange In particular this means that every Kerberos 3 2147483647 AVAILABLE for registration via bug shishi josefsson org V5 packet will be prefixed by a 4 octet length field that indicate 2147483648 RESERVED the length of the Kerberos V5 packet 3 Kerberos 5 STARTTLS Extension 3 Examples 3 1 STARTTLS requested by client extension 1 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 When this message is sent by the client the client is requesting the Client Server server to start TLS negotiation on the TCP stream The client MUST NOT start TLS negotiation immediately Instead the client wait for either a KRB ERROR sent normally prefixed by a 4 octet length integer indicating the server do not understand the set high bit or 4 octets which is to be interpreted as an integer in network byte order where the high bit is set and the remaining 31 bit are interpreted as an integer specifying STARTTLS request accepted by server extension 2 In the first case the client infer that the server do not understand or wish to support STARTTLS and can re try using normal TCP if unprotected Kerberos 5 exchanges are acceptable to the client policy In the latter case it should invoke TLS negotiation on the stream If any other data is received the client MUST close the TCP stream 3 2 STARTTLS request accepted by server extension 2 Kerberos V5 TCP extension mechanism negotiation starts This message should be sent by the server when it has received the 0x70000000 STARTTLS bit extension 1 message The message is an acknowledgment of the 0x00000000 client s request to initiate STARTTLS on the channel The server MUST then invoke a TLS negotiation 3 3 Proceeding after successful TLS negotiation TLS negotiation starts If the TLS negotiation ended successfully possibly also considering ClientHello client or server policies the exchange within the TLS protected ServerHello stream is performed like normal UDP Kerberos 5 exchanges i e there Certificate is no TCP 4 octet length field before each packet Instead each ServerKeyExchange Kerberos packet MUST be sent within one TLS record so the CertificateRequest application can use the TLS record length as the Kerberos 5 packet ServerHelloDone length Certificate ClientKeyExchange CertificateVerify ChangeCipherSpec Finished ChangeCipherSpec Finished 3 4 Proceeding after failed TLS negotiation Kerberos V5 negotiation starts If the TLS negotiation fails possibly due to client or server policy Kerberos V5 AS REQ e g inadequate support of encryption types in TLS or lack of Kerberos V5 AS REP client or server authentication the entity that detect the failure MUST disconnected the connection It is expected that any error messages that explain the error condition is transfered by TLS 3 5 STARTTLS aware KDC Discovery Indicates optional or situation dependent messages that are not always sent 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 Section 7 2 3 of Kerberos 5

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


  • length context value length 5 Output random to key outkey The random to key function is defined in RFC 3961 3 The PA TLS Pre Authentication Type The PA TLS pre authentication type is sent by the client to a KDC It requests that the server uses a different Kerberos V5 reply key If the only tls flag is true the reply key will be derived from only the TLS session If the only tls flag is false the key will Josefsson Expires September 2 2009 Page 4 Internet Draft Deriving Keys From TLS for Kerberos V5 March 2009 be derived from both the TLS session and the the client long term key The exact semantic is described in sub sequent sections The syntax of PA TLS is defined as follows PA TLS EncryptedData PA TLS ENC PA TLS ENC SEQUENCE patimestamp 0 KerberosTime client s time pausec 1 Microseconds OPTIONAL only tls 2 BOOLEAN The client choses the encryption type to use Kerberos V5 RFC4120 mandates support for AES256 CTS HMAC SHA1 96 RFC3962 If the client do not have out of band information to use another encryption type clients MUST use AES256 CTS HMAC SHA1 96 The key used to encrypt the PA TLS ENC is derived using Krb5KeyFromTLS with the following input ltkey empty string ltkey len 0 tlscb the client s TLS Finished message data as described in the tls unique channel binding registration tlscb len length of tlscb etype the encryption type number chosen by the client label EXPORTER Kerberos pre auth key The server process an PA TLS by verifying that the encryption type is acceptable If this fails the server MAY respond with a PA ETYPE INFO TLS as defined below The server proceed and derive the keys and decrypt the PA TLS If this fails the server MUST respond with a KDC ERR PREAUTH FAILED error When the PA TLS is successfully decrypted the KDC needs to decide whether to honor the request or not This is a policy decision that can depend on several reasons including the content of the request When the tls only flag is true the server MUST verify that TLS has authenticated the client e g by a X 509 client certificate or OpenPGP key or Secure Remote Password SRP password The KDC may perform policy checks whether a particular client should be allowed to use this pre authentication type If for any reason the server decides that it does not wish to accept the PA TLS request the server MUST fail the request by returning Josefsson Expires September 2 2009 Page 5 Internet Draft Deriving Keys From TLS for Kerberos V5 March 2009 KDC ERR PREAUTH FAILED An PA ETYPE INFO TLS message is used by the KDC to demand that a client sends a PA TLS The PA ETYPE INFO TLS contains by the KDC acceptable encryption types The PA ETYPE INFO TLS message can be used by a KDC to require that clients uses

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

  • Deriving Keys From TLS for Kerberos V5
    server random context value length context value length 5 Output random to key outkey The random to key function is defined in RFC 3961 TOC 3 The PA TLS Pre Authentication Type The PA TLS pre authentication type is sent by the client to a KDC It requests that the server uses a different Kerberos V5 reply key If the only tls flag is true the reply key will be derived from only the TLS session If the only tls flag is false the key will be derived from both the TLS session and the the client long term key The exact semantic is described in sub sequent sections The syntax of PA TLS is defined as follows PA TLS EncryptedData PA TLS ENC PA TLS ENC SEQUENCE patimestamp 0 KerberosTime client s time pausec 1 Microseconds OPTIONAL only tls 2 BOOLEAN The client choses the encryption type to use Kerberos V5 Neuman C Yu T Hartman S and K Raeburn The Kerberos Network Authentication Service V5 July 2005 RFC4120 mandates support for AES256 CTS HMAC SHA1 96 Raeburn K Advanced Encryption Standard AES Encryption for Kerberos 5 February 2005 RFC3962 If the client do not have out of band information to use another encryption type clients MUST use AES256 CTS HMAC SHA1 96 The key used to encrypt the PA TLS ENC is derived using Krb5KeyFromTLS with the following input ltkey empty string ltkey len 0 tlscb the client s TLS Finished message data as described in the tls unique channel binding registration tlscb len length of tlscb etype the encryption type number chosen by the client label EXPORTER Kerberos pre auth key The server process an PA TLS by verifying that the encryption type is acceptable If this fails the server MAY respond with a PA ETYPE INFO TLS as defined below The server proceed and derive the keys and decrypt the PA TLS If this fails the server MUST respond with a KDC ERR PREAUTH FAILED error When the PA TLS is successfully decrypted the KDC needs to decide whether to honor the request or not This is a policy decision that can depend on several reasons including the content of the request When the tls only flag is true the server MUST verify that TLS has authenticated the client e g by a X 509 client certificate or OpenPGP key or Secure Remote Password SRP password The KDC may perform policy checks whether a particular client should be allowed to use this pre authentication type If for any reason the server decides that it does not wish to accept the PA TLS request the server MUST fail the request by returning KDC ERR PREAUTH FAILED An PA ETYPE INFO TLS message is used by the KDC to demand that a client sends a PA TLS The PA ETYPE INFO TLS contains by the KDC acceptable encryption types The PA ETYPE INFO TLS message can be used by a KDC to require that clients uses PA TLS

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



  •