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

[Simo Sorce <[e-mail]>]

On Fri, 2014-02-14 at 23:47 +0000, Nordgren, Bryce L -FS wrote:
> > For example, in remote access scenarios, the client must initially
> > authenticate to an access point in order to gain full access to the network.
> > Here the client may be unable to directly contact the KDC either because it
> > does not have an IP address, or the access point packet filter does
> > not allow the client to send packets to the Internet before it
> > authenticates to the access point.
> 
> "Remote access" to me means "outside the firewall of the organization
> operating the KDC, which is not exposed to the public internet." What
> you appear to be talking about is authenticating to an access point
> which is operated by the same entity which operates the KDC?
> 
> So the big question is: if an organization is hiding their KDC behind
> a firewall, or they just haven't configured their access points to use
> the KDC as a back end, how is a proxy easier to implement or more
> secure than just configuring access thru their firewall or access
> point? Or really how does providing 1000 routes to the KDC thru any
> public-facing, Kerberos-authenticated service (nfs, web apps, ssh...)
> beat just opening up port 88 to the wide world?
> 
> Not trying to be a pita, just not seeing it yet...

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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York