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-krb5starttls-bootstrap-02.txt - draft-josefsson-krb5starttls-bootstrap.txt
    0 2 draft josefsson krb5starttls bootstrap 0 3 Status of this Memo Status of this Memo This Internet Draft is submitted to IETF in full conformance with the This Internet Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79 provisions of BCP 78 and BCP 79 Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the

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


  • Diff: draft-josefsson-krb5starttls-bootstrap-01.txt - draft-josefsson-krb5starttls-bootstrap-02.txt
    integer ltkey len length of long term key tlscb channel binding data an octet string an integer larger or equal to 0 tlscb channel binding data an octet string tlscb len length of channel binding data tlscb len length of channel binding data a positive integer a positive integer length number of bytes to derive etype number assigned for an encryption type a positive integer label the TLS PRF label to use label the TLS PRF label to use a IANA registered string a IANA registered string Output outkey derived key an length octet string Output protkey derived protocol key Steps Steps 1 Perform the TLS Exporter step 1 Set length to the key generation seed length K for the encryption type enctype as per RFC 3961 2 Set context value to the concatenation of ltkey followed by tlscb Note that ltkey may be empty 3 Derive the value for context value length from the sum of ltkey len and tlscb len 4 Perform the TLS Exporter step outkey PRF master secret label outkey PRF master secret label SecurityParameters client random SecurityParameters client random SecurityParameters server random SecurityParameters server random context value length context value context value length context value length length The context value should be the concatenation of inkey 5 Output random to key outkey The random to key function is followed by tlscb defined in RFC 3961 Consequently the length of context value which used to 3 The PA TLS Pre Authentication Type derived context value length will be the sum of inkey len and tlscb len The values of length and label are as the inputs to this The PA TLS pre authentication type is sent by the client to a KDC function 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 3 Output the derived key outkey The syntax of PA TLS is defined as follows 3 Reply Key Strengthening PA TLS EncryptedData PA TLS ENC If the client do not yet have trust anchors for the KDC it should PA TLS ENC SEQUENCE delay verification of the server certificate patimestamp 0 KerberosTime client s time pausec 1 Microseconds OPTIONAL only tls 2 BOOLEAN To signal that the client wishes the KDC to strengthen the reply key The client choses the encryption type to use Kerberos V5 RFC4120 using keying material derived from the TLS session it sends a pre mandates support for AES256 CTS HMAC SHA1 96 RFC3962 If the authentication mechanism called pa krb5starttls strengthen It has client do not have out of band information to use another encryption a pdata type integer value of TBD type clients MUST use AES256 CTS HMAC SHA1 96 The pre authentication structure is defined in RFC 4120 as The key used to encrypt the PA TLS ENC is derived using Krb5KeyFromTLS with the following input PA DATA SEQUENCE ltkey empty string NOTE first tag is 1 not 0 ltkey len 0 padata type 1 Int32 tlscb the client s TLS Finished message data padata value 2 OCTET STRING might be encoded AP REQ as described in the tls unique channel binding registration tlscb len length of tlscb etype the encryption type number chosen by the client label Kerberos pre auth key The content of the padata value should be the DER encoding of the The server process an PA TLS by verifying that the encryption type is empty string 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 receiving the request to use the pa krb5starttls strengthen When the PA TLS is successfully decrypted the KDC needs to decide pre authentication message the KDC needs to decide whether to honor whether to honor the request or not This is a policy decision that it or not This is a policy decision that can depend on several can depend on several reasons including the content of the request reasons including the content of the request If the KDC decides that it does not wish to honor the pa krb5starttls strengthen When the tls only flag is true the server MUST verify that TLS has request the KDC MUST fail the request by returning authenticated the client e g by a X 509 client certificate OpenPGP key or 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 KDC ERR PREAUTH FAILED When the KDC decides to honor the client s request it will process An PA ETYPE INFO TLS message is used by the KDC to demand that a the incoming request as usual except that the KDC REP reply key is client sends a PA TLS The PA ETYPE INFO TLS contains by the KDC post processed The post processing uses Keying Material Exporters acceptable encryption types The PA ETYPE INFO TLS message can be for Transport Layer Security TLS I D ietf tls extractor by used by a KDC to require that clients uses PA TLS or to require that invoking the Krb5KeyFromTLS function with the following inputs clients send a PA TLS using some particular encryption types inkey user s long term shared secret The PA ETYPE INFO TLS is used as follows The KDC sends a KRB ERROR inkey len length of inkey packet with the KDC ERR PREAUTH REQUIRED error code and

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

  • Diff: draft-josefsson-krb5starttls-bootstrap-00.txt - draft-josefsson-krb5starttls-bootstrap-01.txt
    TLS channel The mechanism to achieve the above goals is for the KDC to strengthen The mechanism to achieve the above goals is for the KDC to strengthen the Kerberos V5 reply key using keying material derived from the TLS the Kerberos V5 reply key using keying material derived from the TLS channel RFC5246 using the algorithm specified in Keying Material channel RFC5246 using the algorithm specified in Keying Material Exporters for Transport Layer Security TLS Exporters for Transport Layer Security TLS I D ietf tls extractor I D ietf tls extractor The key words MUST MUST NOT REQUIRED SHALL SHALL NOT The document also describes a pre authentication mechanism that can SHOULD SHOULD NOT RECOMMENDED MAY and OPTIONAL in this be used to achieve document are to be interpreted as described in RFC 2119 RFC2119 2 Protocol The client and KDC MUST support Kerberos V5 over TLS I D josefsson kerberos5 starttls If the client do not yet have trust anchors for the KDC it should disable verification of the server certificate To signal that the client wishes the KDC to strengthen the reply key o Allow use of Kerberos V5 without a long term shared secret between using keying material derived from the TLS session it sends a pre the user and the KDC authentication mechanism called pa krb5starttls bootstrap It has a pdata type integer value of TBD The pre authentication structure is defined in RFC 4120 as This goal is achieved by having the client authenticate itself using TLS and having the KDC request that the client send a PA ENC TIMESTAMP pre authentication data encrypted using a key derived from the TLS channel If successful the KDC will encrypt the response using a reply key derived only from the TLS channel PA DATA SEQUENCE This document requires that both the client and the KDC MUST support NOTE first tag is 1 not 0 Kerberos V5 over TLS I D josefsson kerberos5 starttls padata type 1 Int32 padata value 2 OCTET STRING might be encoded AP REQ The content of the padata value should be the DER encoding of the The key words MUST MUST NOT REQUIRED SHALL SHALL NOT empty string SHOULD SHOULD NOT RECOMMENDED MAY and OPTIONAL in this document are to be interpreted as described in RFC 2119 RFC2119 When receiving the request to use the pa krb5starttls bootstrap 2 TLS Exporter Function pre authentication message the KDC needs to decide whether to honor it or not This is a policy decision that can depend on several reasons including the content of the request If the KDC decides that it does not wish to honor the pa krb5starttls bootstrap request the KDC MUST fail the request by returning KDC ERR PREAUTH FAILED When the KDC decides to honor the client s request it will process The following function Krb5KeyFromTLS is used elsewhere to derive the incoming request as usual except that the KDC REP reply key is keys from a TLS session post processed as follows The post processing uses Keying Material Exporters for Transport Layer Security TLS I D ietf tls extractor The channel binding input tlscb value MUST be the client s TLS Finished message data as described in the tls unique channel binding registration StrengthenKrb5ReplyKeyUsingTLS inkey inkey len Krb5KeyFromTLS inkey inkey len tlscb tlscb len length label tlscb tlscb len Input inkey encryption key an octet string Input inkey encryption key an octet string inkey len length of encryption key inkey len length of encryption key a positive integer a positive integer tlscb channel binding data an octet string tlscb channel binding data an octet string tlscb len length of channel binding data tlscb len length of channel binding data a positive integer a positive integer length number of bytes to derive a positive integer label the TLS PRF label to use a IANA registered string Output outkey derived key a inlen octet string Output outkey derived key a n length octet string Steps Steps 1 Perform the TLS Exporter step 1 Perform the TLS Exporter step outkey PRF master secret label outkey PRF master secret label SecurityParameters client random SecurityParameters client random SecurityParameters server random SecurityParameters server random context value length context value context value length context value length length The context value should be the concatenation of inkey The context value should be the concatenation of inkey followed by tlscb followed by tlscb Consequently the length of context value which used to Consequently the length of context value which used to derived context value length will be the sum of derived context value length will be the sum of inkey len and tlscb len inkey len and tlscb len Use the value of inkey len as the value of the length The values of length and label are as the inputs to this variable function 3 Output the derived key outkey 3 Output the derived key outkey The client will strengthen the KDC REP reply key using the same 3 Reply Key Strengthening If the client do not yet have trust anchors for the KDC it should delay verification of the server certificate To signal that the client wishes the KDC to strengthen the reply key using keying material derived from the TLS session it sends a pre authentication mechanism called pa krb5starttls strengthen It has a pdata type integer value of TBD 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 The content of the padata value should be the DER encoding of the empty string When receiving the request to use the pa krb5starttls strengthen pre authentication message the KDC needs to decide whether to honor it or not This is a policy decision that can depend on several reasons including the content of the request If the KDC decides that it does not wish to honor the pa krb5starttls strengthen

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


  • that the KDC knows your encryption key i e your password The key words MUST MUST NOT REQUIRED SHALL SHALL NOT Josefsson Expires February 1 2010 Page 4 Internet Draft Protecting Kerberos V5 with TLS July 2009 SHOULD SHOULD NOT RECOMMENDED MAY and OPTIONAL in this document are to be interpreted as described in RFC 2119 RFC2119 Josefsson Expires February 1 2010 Page 5 Internet Draft Protecting Kerberos V5 with TLS July 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 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 1 2010 Page 6 Internet Draft Protecting Kerberos V5 with TLS July 2009 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 February 1 2010 Page 7 Internet Draft Protecting Kerberos V5 with TLS July 2009 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 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

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


  • 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 10 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 10 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 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 September 10 2009 Page 6 Internet Draft Protecting Kerberos V5 with TLS March 2009 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 September 10 2009 Page 7 Internet Draft Protecting Kerberos V5 with TLS March 2009 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 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

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


  • client random SecurityParameters server random context value 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 7 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 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 OpenPGP key or 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 7 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

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


  • as described in RFC 2119 RFC2119 Josefsson Expires September 4 2009 Page 4 Internet Draft Kerberos V5 Reply Keys From TLS March 2009 2 TLS Exporter Function The following function Krb5KeyFromTLS is used elsewhere to derive keys from a TLS session Krb5KeyFromTLS inkey inkey len tlscb tlscb len length label Input inkey encryption key an octet string inkey len length of encryption key a positive integer tlscb channel binding data an octet string tlscb len length of channel binding data a positive integer length number of bytes to derive a positive integer label the TLS PRF label to use a IANA registered string Output outkey derived key an length octet string Steps 1 Perform the TLS Exporter step outkey PRF master secret label SecurityParameters client random SecurityParameters server random context value length context value length The context value should be the concatenation of inkey followed by tlscb Consequently the length of context value which used to derived context value length will be the sum of inkey len and tlscb len The values of length and label are as the inputs to this function 3 Output the derived key outkey Josefsson Expires September 4 2009 Page 5 Internet Draft Kerberos V5 Reply Keys From TLS March 2009 3 Reply Key Strengthening If the client do not yet have trust anchors for the KDC it should delay verification of the server certificate To signal that the client wishes the KDC to strengthen the reply key using keying material derived from the TLS session it sends a pre authentication mechanism called pa krb5starttls strengthen It has a pdata type integer value of TBD 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 The content of the padata value should be the DER encoding of the empty string When receiving the request to use the pa krb5starttls strengthen pre authentication message the KDC needs to decide whether to honor it or not This is a policy decision that can depend on several reasons including the content of the request If the KDC decides that it does not wish to honor the pa krb5starttls strengthen request the KDC MUST fail the request by returning KDC ERR PREAUTH FAILED When the KDC decides to honor the client s request it will process the incoming request as usual except that the KDC REP reply key is post processed The post processing uses Keying Material Exporters for Transport Layer Security TLS I D ietf tls extractor by invoking the Krb5KeyFromTLS function with the following inputs inkey user s long term shared secret inkey len length of inkey tlscb the client s TLS Finished message data as described in the tls unique channel binding registration tlscb len length of tlscb length same as inkey len label Kerberos V5 strengthen key The client will strengthen its local KDC REP reply key using the same procedure

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


  • response using the user s password Only the correct KDC will be able to generate a Kerberos V5 response using the user s password and the secrets derived from the TLS channel o Securely distribute the trust anchors used by the Key Distribution Center KDC in a Kerberos V5 realm This is achieved the same way as before but rather than remembering the server certificate it remembers the trust anchor o The ability to use Kerberos V5 over TLS without having to validate the server certificates The mechanism to achieve the above goals is for the KDC to strengthen the Kerberos V5 reply key using keying material derived from the TLS channel RFC5246 using the algorithm specified in Keying Material Exporters for Transport Layer Security TLS I D ietf tls extractor 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 RFC2119 Josefsson Expires September 3 2009 Page 3 Internet Draft Kerberos V5 Reply Key Strengthening March 2009 2 Protocol The client and KDC MUST support Kerberos V5 over TLS I D josefsson kerberos5 starttls If the client do not yet have trust anchors for the KDC it should disable verification of the server certificate To signal that the client wishes the KDC to strengthen the reply key using keying material derived from the TLS session it sends a pre authentication mechanism called pa krb5starttls bootstrap It has a pdata type integer value of TBD 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 The content of the padata value should be the DER encoding of the empty string When receiving the request to use the pa krb5starttls bootstrap pre authentication message the KDC needs to decide whether to honor it or not This is a policy decision that can depend on several reasons including the content of the request If the KDC decides that it does not wish to honor the pa krb5starttls bootstrap request the KDC MUST fail the request by returning KDC ERR PREAUTH FAILED When the KDC decides to honor the client s request it will process the incoming request as usual except that the KDC REP reply key is post processed as follows The post processing uses Keying Material Exporters for Transport Layer Security TLS I D ietf tls extractor The channel binding input tlscb value MUST be the client s TLS Finished message data as described in the tls unique channel binding registration Josefsson Expires September 3 2009 Page 4 Internet Draft Kerberos V5 Reply Key Strengthening March 2009 StrengthenKrb5ReplyKeyUsingTLS inkey inkey len tlscb tlscb len Input inkey encryption key an octet string inkey len length of encryption key a positive integer tlscb channel binding data an octet string tlscb len length of channel binding data a positive integer Output

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



  •