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

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

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

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.