AW: Armor key negotiation in FAST

[Greg Hudson]

On 11/22/2012 08:07 AM, Simon.Jansen at t-systems.com wrote:
> 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?

The privileged process needs to provide the sub-session key to the
unprivileged process.  (If you reread that sentence, it says that three
pieces of information are given, not two.)

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

A strengthen-key must be used if encrypted challenge is used (see
section 5.4.6).

I don't see any more general text mandating that a strengthen-key be
used if the reply key isn't altered by a preauth mech, but I would
expect it to be done.  The MIT implementation always supplies a
strengthen-key.