Re: [kitten] I-D Action: draft-ietf-kitten-iakerb-01.txt

["Nordgren, Bryce L -FS" <[e-mail]>]

-- Clarifying discussion on draft-ietf-kitten-iakerb-01.txt --

> The remote access protocol might not be able to allow any traffic other than EAP
> until the user is authenticated.

So if I understand this correctly, the current situation is that the remote access point could be configured to use Kerberos as a backend, serving as a kind of one-way identity gateway between two protocols. The proposed improvement is to eliminate the need to be a gateway by allowing the access point to relay messages between a kerberos client and a KDC which otherwise have no means of communication. The net change is that clients use Kerberos instead of whatever was used previously, access points require new firmware, and clients get a TGT earlier in the process.

> The most immediate use case you may think about is GSSAPI authenticated
> VPN, where the KDC is inaccessible until you get on the VPN, w/o IAKERB you
> have a Catch22 situation.

My current situation is that I power up my laptop at home, log into Windows using cached credentials, manually start the VPN client, provide credentials to the VPN server using some means, and the VPN server validates this information using one of two backends (LDAP username/password or lincpass/HSPD-12 card/PKI). Again the VPN server acts as a kind of identity gateway and again the proposed improvement is to eliminate the need to be a gateway. Looks like the net change may also be same as above.


-- Comments on draft-ietf-kitten-iakerb-01.txt --

Comment 1: Clarify exactly what the benefit is. Why are the current gateway strategies not good enough and what specifically is gained by implementing IAKERB? (Should be easy.)

Comments 2 and 3 are really "discussion items". (below)

Comment 4: "Proxy" has already been defined in 4120. Stress that the usage of "proxy" in this document does not imply that the client allows its tickets to be used by "others".

Comment 5: This approach may be summarized as a "message relay" from client to app to KDC. Compare and contrast this approach with a "ticket relay", where a strawman (fake) KDC requests and relays proxiable and/or forwardable tickets from the "real" KDC on the client's behalf, using its own identity. Outline the tradeoffs in terms of compatibility with deployed Krb5 clients and KDCs, amount of "extension" required, types of situations to which the approach applies, state information required at the relay point, and security implications. Make the case that "message relay" is a superior strategy, and show that alternatives were considered and rejected.

Comment 6: This message relay approach intentionally establishes many persistent "men in the middle", potentially piggybacking on every kerberized app you have.  Note this in the security considerations.


-- Technical discussion about draft-ietf-kitten-iakerb-01.txt --

Comments 2 and 3 boil down to: should an IAKERB enabled Kerberos client keep track of KDC connection failures so that it can try and get tickets when it later discovers a path to the KDC? Conversely, should an IAKERB enabled Kerberos client keep track of proxies so that it doesn't just give up when it can't contact the KDC? Details below.

2nd comment details...Proxies may be asked to acquire tickets for other services, and the order in which services are accessed by clients  seems to matter. (Person A is at home, accessing web services "X" and "Y". Both X and Y are kerberized. X is IAKERB enabled and Y is not. If A connects to X first, it SHOULD request a ticket for Y using X once it discovers that Y isn't IAKERB enabled. If A connects to Y first, it has no TGT nor a means of getting one, so Y must behave like a gateway. After A connects to X, and "discovers" a pathway to its KDC, should it then request tickets for Y? How is Y informed that A now has a ticket? ) This may not require much in the way of verbage, but I think it probably should be included. The proposed improvement is to eliminate gatewaylike behavior.

3rd comment details...what if the service also does not have a path to the KDC? In the VPN example above, I log in to my host using cached credentials. Once I connect to an IAKERB proxy (VPN server), should the host try to grab a valid ticket?


Bryce





This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.