Subject: RE: Question on draft-ietf-nasreq-criteria-02.txt

From: "Bernard Aboba (Exchange)" <[email-masked]>
Date: Tue, 12 Oct 1999 09:55:45 -0700

>One issue with EAP Kerberos is that it is not inter-domain.  I am not sure
>how the EAP over RADIUS would work in an interdomain situation, but it is
>certainly a requirement that if it is part of the AAA protocol that it be
>able to work across domains.

I'm curious as to why you think that EAP-KRB can't work inter-realm. From
what I can see, the main obstacles relate to topology and the limitations of
PPP authentication (and Kerberos). At first glance, EAP over RADIUS doesn't
seem like an obstacle. 

In dialup we need to assume that the client isn't connected to the Internet
until after IPCP completes. As a result, it isn't possible for the client to
have general Internet connectivity during the authentication. This means
that the client can talk to the AAA server via EAP but doesn't have the
general ability to reach any node on the Internet. 

This means that the client can't get to its home KDC directly in order to
obtain a TGT, and then ask for a ticket to the local realm's KDC. The way
around this is for the AAA server to forward packets to home KDCs on the
user's behalf. 

For example, the client can send the AAA server an AS_REQ and the AAA server
can forward this to the home KDC on the client's behalf and get the AS_REP
back and send this to the client. As long as the client is corresponding
with KDCs that the AAA server is willing to forward to then it would seem
like this could work. Note that certificate-based EAP protocols like EAP-TLS
don't encounter this issue since the local AAA server can validate the cert.

I would note that the above issues only occur during the first
authentication. Subsequent to that the client can use the PPP service ticket
that it obtained in the first authentication, and re-authenticate in an
expedited manner. 

So from what I can see there isn't much that a AAA protocol can do to make
this easier. 

>A second point is that reauthentication and reauthorization are done for
>different reasons.  Reauthentication is done to verify that this is still
>the same user.  Reauthorization is done either because new resources 
>are to needed to support the existing service (e.g. adding another ISDN 
>channel to a connection) or to verify that the current authorization is >
>still valid.

Sure. While the authentication might be expedited due to the client's
posession of a reusable ticket, this doesn't affect the authorization
process. 

>A final comment - I think the concept of delegation is very interesting
>here.  The idea of delegating the authentication to the NAS by the user.  

Actually, the forwarding described above would be from the user to the AAA
server (KRB Forwardable flag set). Since few NASes understand Kerberos (or
want to) I don't think that the NAS will generally have the smarts to handle
this. This creates a bit of an issue since the session key will be held by
the AAA server and the client, not by the client and the NAS. So if you want
to do something with the session key (like encrypt the PPP session) you've
got an issue. 

>In other contexts, an authorization server may delegate some or all
>authorization to other authorization servers.  I am not sure how to
>formalize this, but it might be worth a try.

Well, in Kerberos it's possible for the KDC to send back authorization in
the PACS field. I'd have to think through the sequence of events but
potentially the local KDC could take the PACS field into account in issuing
its own tickets to the user.