Armor key negotiation in FAST

[Greg Hudson]

On 11/12/2012 05:37 AM, Simon.Jansen at t-systems.com wrote:
> Why is the armor built and why don't they use simply the long-term key of the host?

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 5.4.1.1 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.)

Using a ticket rather than the long-term key also provides the KDC a
weak guarantee of freshness.

> From my current point of view they want a fresh armorkey for each conversation to decrease the vulnerability to replay attacks. But referring to page 31 of the RFC 6113 a nonce is included in the client request. So the chance to mount a replay attack should be decreased already. Are there any other advantages that come up with the generation of the armor key?

The nonce is only a 32-bit value (RFC 4120 prohibits reuse, but that's
difficult to ensure), and is not included in KRB-ERROR responses.