locked
[MS-PKCA].pdf: decrypting TGT included in AS-REP packet RRS feed

  • Question

  • Hello

    We want to implement RDP kerberos login using smartcard.
    The scenario is sending an AS-REQ packet and receiving an AS-REP packet.
    And as specified in [MS-PKCA], Chapter 4.3, the AS-REP TGT ticket includes the authorization_data field (where the NTpassword can be found).

    But we don't know how to decrypt the TGT.
    In the AS-REP packet, we succeeded to decrypt:
       - the PA-PK-AS-REP section (using smartcard to decrypt the encryption key and using this encryption key to decrypt the signedData)
       - the enc-part section (with the encryption key contained in the signed data).

    How the TGT can be decrypted?
      - The decrypted session key contained in enc-part section doesn't help
      - the username's password is not known (only the smartcard PIN code is used)

     
    Thank you

    Vincent


    Tuesday, April 12, 2016 9:43 AM

Answers

  • We worked with Vincent offline and here is the summary of the answer:

    For the initial question, the TGT is normally encrypted by the KDC key. As a result, the TGT is opaque to the client.
    Only the KDC decrypts the TGT, as specified in Kerberos standard.

    Once the client received the AS-PK-REP, it can request a user-to-user TGS with sName as the user name, and decrypt the resulting PAC with the session key. The PAC shall then have the unicodePwd (NTLM_SUPPLEMENTAL_CREDENTIAL).
    In the TGS’s request body, the client needs to use the ENC-TKT-IN-SKEY option and supply the TGT in the additional tickets.
    See RFC4120 for full spec of user-to-user.
    RFC4120
    3.3.1.  Generation of KRB_TGS_REQ Message
    . . .
    As in the AS exchange, the client MAY specify a number of options in
       the KRB_TGS_REQ message.  One of these options is the ENC-TKT-IN-SKEY
       option used for user-to-user authentication.  An overview of user-
       to-user authentication can be found in Section 3.7.  When generating
       the KRB_TGS_REQ message, this option indicates that the client is
       including a TGT obtained from the application server in the
       additional tickets field of the request and that the KDC SHOULD
       encrypt the ticket for the application server using the session key
       from this additional ticket, instead of a server key from the
       principal database.
    2.9.2.  ENC-TKT-IN-SKEY
       In its basic form, the Kerberos protocol supports authentication in a
       client-server setting and is not well suited to authentication in a
       peer-to-peer environment because the long-term key of the user does
       not remain on the workstation after initial login.  Authentication of
       such peers may be supported by Kerberos in its user-to-user variant.
       The ENC-TKT-IN-SKEY option supports user-to-user authentication by
       allowing the KDC to issue a service ticket encrypted using the
       session key from another TGT issued to another user.  The
       ENC-TKT-IN-SKEY option is honored only by the ticket-granting
       service.  It indicates that the ticket to be issued for the end
       server is to be encrypted in the session key from the additional
       second TGT provided with the request.  See Section 3.3.3 for specific
       details.
    3.3.3.  Generation of KRB_TGS_REP Message
    . . .
       If the ENC-TKT-IN-SKEY option has been specified and an additional
       ticket has been included in the request, it indicates that the client
       is using user-to-user authentication to prove its identity to a
       server that does not have access to a persistent key.  Section 3.7
       describes the effect of this option on the entire Kerberos protocol.
       When generating the KRB_TGS_REP message, this option in the
       KRB_TGS_REQ message tells the KDC to decrypt the additional ticket
       using the key for the server to which the additional ticket was
       issued and to verify that it is a TGT.  If the name of the requested
       server is missing from the request, the name of the client in the
       additional ticket will be used.  Otherwise, the name of the requested
       server will be compared to the name of the client in the additional
       ticket.  If it is different, the request will be rejected.  If the
       request succeeds, the session key from the additional ticket will be
       used to encrypt the new ticket that is issued instead of using the
       key of the server for which the new ticket will be used.
    . . .
    The ciphertext part of the response in the KRB_TGS_REP message is
       encrypted in the sub-session key from the Authenticator, if present,
       or in the session key from the TGT.  It is not encrypted using the
       client's secret key.  Furthermore, the client's key's expiration date
       and the key version number fields are left out since these values are
       stored along with the client's database record, and that record is
       not needed to satisfy a request based on a TGT.
    Monday, June 27, 2016 10:42 PM

All replies

  • Hi Vincent,

    Thank you for your question.  An engineer from the protocols team will contact you soon.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Tuesday, April 12, 2016 2:19 PM
  • Vincent,

    Can you contact us at this email dochelp <at > Microsoft <dot> com. Please mention this thread.

    Thank you,

    Edgar

    Tuesday, April 12, 2016 3:41 PM
  • Hi Vincent,

    Sorry for offtopic.

    As I see, you are working on AS-REP so perhaps you know the answer for this question:

    https://social.msdn.microsoft.com/Forums/en-US/b5e808d3-43b6-4a1a-8a61-13cc37353e41/questions-about-papkasreq-from-pkinit?forum=os_windowsprotocols   

    ?

    Do you know what content is used to calculate signature for PA-PK-AS-REQ?

     

    Thanks,

    Martin
    Wednesday, April 13, 2016 10:19 AM
  • We worked with Vincent offline and here is the summary of the answer:

    For the initial question, the TGT is normally encrypted by the KDC key. As a result, the TGT is opaque to the client.
    Only the KDC decrypts the TGT, as specified in Kerberos standard.

    Once the client received the AS-PK-REP, it can request a user-to-user TGS with sName as the user name, and decrypt the resulting PAC with the session key. The PAC shall then have the unicodePwd (NTLM_SUPPLEMENTAL_CREDENTIAL).
    In the TGS’s request body, the client needs to use the ENC-TKT-IN-SKEY option and supply the TGT in the additional tickets.
    See RFC4120 for full spec of user-to-user.
    RFC4120
    3.3.1.  Generation of KRB_TGS_REQ Message
    . . .
    As in the AS exchange, the client MAY specify a number of options in
       the KRB_TGS_REQ message.  One of these options is the ENC-TKT-IN-SKEY
       option used for user-to-user authentication.  An overview of user-
       to-user authentication can be found in Section 3.7.  When generating
       the KRB_TGS_REQ message, this option indicates that the client is
       including a TGT obtained from the application server in the
       additional tickets field of the request and that the KDC SHOULD
       encrypt the ticket for the application server using the session key
       from this additional ticket, instead of a server key from the
       principal database.
    2.9.2.  ENC-TKT-IN-SKEY
       In its basic form, the Kerberos protocol supports authentication in a
       client-server setting and is not well suited to authentication in a
       peer-to-peer environment because the long-term key of the user does
       not remain on the workstation after initial login.  Authentication of
       such peers may be supported by Kerberos in its user-to-user variant.
       The ENC-TKT-IN-SKEY option supports user-to-user authentication by
       allowing the KDC to issue a service ticket encrypted using the
       session key from another TGT issued to another user.  The
       ENC-TKT-IN-SKEY option is honored only by the ticket-granting
       service.  It indicates that the ticket to be issued for the end
       server is to be encrypted in the session key from the additional
       second TGT provided with the request.  See Section 3.3.3 for specific
       details.
    3.3.3.  Generation of KRB_TGS_REP Message
    . . .
       If the ENC-TKT-IN-SKEY option has been specified and an additional
       ticket has been included in the request, it indicates that the client
       is using user-to-user authentication to prove its identity to a
       server that does not have access to a persistent key.  Section 3.7
       describes the effect of this option on the entire Kerberos protocol.
       When generating the KRB_TGS_REP message, this option in the
       KRB_TGS_REQ message tells the KDC to decrypt the additional ticket
       using the key for the server to which the additional ticket was
       issued and to verify that it is a TGT.  If the name of the requested
       server is missing from the request, the name of the client in the
       additional ticket will be used.  Otherwise, the name of the requested
       server will be compared to the name of the client in the additional
       ticket.  If it is different, the request will be rejected.  If the
       request succeeds, the session key from the additional ticket will be
       used to encrypt the new ticket that is issued instead of using the
       key of the server for which the new ticket will be used.
    . . .
    The ciphertext part of the response in the KRB_TGS_REP message is
       encrypted in the sub-session key from the Authenticator, if present,
       or in the session key from the TGT.  It is not encrypted using the
       client's secret key.  Furthermore, the client's key's expiration date
       and the key version number fields are left out since these values are
       stored along with the client's database record, and that record is
       not needed to satisfy a request based on a TGT.
    Monday, June 27, 2016 10:42 PM