On 11/12/2012 05:37 AM, [email protected] 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. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
