AW: Armor key negotiation in FAST
Simon.Jansen at t-systems.com
Thu Nov 22 08:07:35 EST 2012
> One of the design goals of FAST is to allow a privileged process to hand out a TGT for the host principal to an unprivileged process for use as an armor ticket. See section RFC 6113 section 18.104.22.168 where it talks about AD-fx-fast-armor. Armoring with the host's long-term key would require the privileged process to perform the armored AS request. (I'm also not sure what you would propose in place of FAST TGS, which currently uses the user's TGT to construct the armor key.)
Ok. Thank you for clarifying that point.
So if I got that aspect right the host key is not used to armor because the AS request for the user principal should be performed in an unprivileged process that should not know the host's long-term key.
The mentioned section says that the privileged process provides the armor ticket and an authenticator to the unprivileged process. The authenticator that includes the sub-session key is encrypted with the session key and the ticket is encrypted with the TGS key. But the unprivileged process has to know the session key to extract the sub-session key from the authenticator. Is the session key also provided to the unprivileged process or how does the process know the key?
I have a further question, this time regarding to the AS reply for user principals from the KDC. Without FAST the enc-part of the message is encrypted with the user's long-term key. Is the strengthen-key field in the PA-FX-FAST padata used to built a stronger key for encrypting the enc-part of the AS reply or is a completely different key used? The RFC standard says on page 32 that the strengthen-key may be included in the AS reply. But if the strengthening mechanism is not used and the user's long-term key is used for encryption the enc-part is vulnerable to dictionary attacks.
More information about the Kerberos