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

From: [email-masked]
Date: Fri, 14 Feb 2014 13:45:26 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

        Title           : Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB)
        Authors         : Jim Schaad
                          Larry Zhu
                          Jeffery Altman
	Filename        : draft-ietf-kitten-iakerb-01.txt
	Pages           : 11
	Date            : 2014-02-14

Abstract:
   This document defines extensions to the Kerberos protocol and the
   GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
   exchange messages with the KDC using the GSS-API acceptor as the
   proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
   With these extensions a client can obtain Kerberos tickets for
   services where the KDC is not accessible to the client, but is
   accessible to the application server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-iakerb/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-kitten-iakerb-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-iakerb-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Fri, 14 Feb 2014 23:47:13 +0000

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

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Feb 2014 17:58:06 -0600

> Not trying to be a pita, just not seeing it yet...

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

Also, to use Kerberos outside the firewall would require configuring
the firewall to permit DNS and Kerberos, which might be too difficult,
and anyways might be considered risky (considering all that can be
smuggled in DNS and Kerberos messages).

Nico
--

---

From: Simo Sorce <[email-masked]>
Date: Sat, 15 Feb 2014 12:21:58 -0500

On Fri, 2014-02-14 at 23:47 +0000, Nordgren, Bryce L -FS wrote:
> "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?
> 

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

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Sat, 15 Feb 2014 20:23:22 +0000

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

> 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