Thanks again for your answer. > The Ticket identifies the TGT used to armor the request and contains the > session key; the Authenticator > (encrypted in the session key) contains the subkey.
So the security of the whole tunnel is based on the strength of the long-term host key. Theoretically an attacker would be able to obtain a host TGT that is encrypted with the host key because pre-authentication is in most cases not required. On that TGT he can start offline attacks to get the key that was used for encryption. If he gets the key he can decrypt other requests and is able to get the session keys of other conversations and with the session key he can get the subkey from the authenticator. Finally the attacker has all information needed to rebuild the armor key and though is able to decrypt FAST tunneled messages. Remember everything is theoretically regardless of the time factor that is needed to find the correct host key. Is there a special reason why a complete new key is created for armoring the requests? Why isn't just the session key used? Regards, Simon -----Ursprüngliche Nachricht----- Von: Greg Hudson [mailto:[email protected]] Gesendet: Montag, 29. Oktober 2012 15:04 An: Jansen, Simon Cc: [email protected] Betreff: Re: Armor key negotiation in FAST On 10/29/2012 04:26 AM, [email protected] wrote: > 1. Obtain a TGT (called armor TGT) for the host principal without FAST > armoring but with pre-authentication (encrypted timestamp) It isn't really necessary to use preauth with a host key, but you certainly can. > 2. Extract the session key and the subkey from the armor TGT and build > the armor key with the KRB-FX-CF2 function You don't get the subkey from the armor TGT; you choose one randomly. > 3. Use the built armor key for encrypting the AS conversation of the > user principal and for ensuring the integrity Yes. > Referring to the RFC standard on page 27 the KrbFastArmoredReq includes an > armor field of the type KrbFastArmor that identifies the armor key. Does this > field include the information which host principal was used to build the > armor key or how does the KDC know which TGT was used for armoring the > request? The KrbFastArmor contains an RFC 4120 AP-REQ, which contains a Ticket and an Authenticator. The Ticket identifies the TGT used to armor the request and contains the session key; the Authenticator (encrypted in the session key) contains the subkey. Those two pieces together allow the KDC to construct the same armor key as the client did. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
