>>>>> "Nico" == Nico Williams <[email protected]> writes:
Nico> Options to make this happen: a) Make the GSS-EAP client aware
Nico> of the AS exchange and give it the bits it needs to recover
Nico> the reply key and extract the credentials. Now how to get a
Nico> service ticket for the RP in a round-trip efficient way?
Nico> Well, have the RP mint one and be done, say. Or define a new
Nico> way to use a TGT as an additional ticket with which to get the
Nico> desired service ticket (sortof like reverse user-to-user).
I would prefer any Kerberos knowledge to be optional in gss-eap so I
Nico> don't like this.
Nico> b) Define a new AS-like exchange where the final reply in a
Nico> successful case contains a KRB-CRED, so that multiple tickets
Nico> may be issued at once, then apply the solution above this one.
dito
Nico> c) Add some AS-REQ flags so that the AS-REP will contain an
Nico> pre-auth element that contains a KRB-CRED in it with the
Nico> desired tickets. In this case the enc-part of the AS-REP will
Nico> be useless and will be thrown out.
Nico> d) Add some AS-REQ flags so that the AS-REP's pre-auth method
Nico> data will contain an embedded KRB-CRED (in the case of GSS
Nico> pre-auth probably using the Null enctype and embedded in a
Nico> wrap token).
I don't see the difference between C and D.
Also, this all seems like it focuses on the part of the problem where I
see lots of options rather than the part of the problem I don't know how
to deal with.
Namely, I don't understand how to make the key hierarchy work out right
across the gss-preauth boundary without either
1) building Kerberos knowledge into the initiator
2) having the acceptor gain the TGT key.
Obviously, since I'm willing to go to EAP preauth instead of gss
preauth, I'm OK building what amounts to EAP knowledge into the acceptor
and preauth method and playing with the reply key.
I'd like to find something cleaner.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
