Subject: RE: New draft coming your way

From: "Mike Swift (NT)" <[email-masked]>
Date: Fri, 7 Nov 1997 11:00:40 -0800

This is indeed similar to Charon. However, there are a few different design
goals. This protocol works through the GSS-API, so it does not need to worry
about packetizing or being 6 bit clean. That encoding and packetizing can be
handled by a higher level application. More importantly, no changes are
required to the KDC to support this protocol. This makes a big difference
because while it is reasonable to install new client & server software
upgrading the KDC is often not a feasible option.

In addition, the option in this draft of procuring a service ticket directly
and skipping the TGS request for a session ticket can help lessen bandwidth
requirements for authenticating to a dial-up server.

> -----Original Message-----
> From:	Derek Atkins [SMTP:[email-masked]]
> Sent:	Friday, November 07, 1997 8:46 AM
> To:	Mike Swift (NT)
> Cc:	Doug Engert; [email-masked]
> Subject:	Re: New draft coming your way
> 
> Take a look at "Charon: Kerberos Extensions for Authentication over
> Secondary Networks", which made extensions to Kerberos to allow secure
> authentication to a server using in-band signalling.  This is most
> useful for secure authentication of dialup connections, where you
> don't have IP connectivity from the client to the KDC.
> 
> In your particular case, the firewall/terminal server would act as the
> "login host", to which the user truly authenticates securely.  Based
> on that authentication, the firewall/terminal server can grant
> connectivity to the rest of the network.
> 
> Take a look at http://web.mit.edu/warlord/www/thesis.ps
> 
> -derek
> 
> "Mike Swift (NT)" <[email-masked]> writes:
> 
> > 
> > Dialup authentication is one of the primary motiviations for this draft.
> By
> > allowing Kerberos to be used before the network is available clients can
> > authenticate to the dial-in server or firewall before being granted
> access
> > to the rest of the network.
> > 
> > - Mike
> > 
> > > -----Original Message-----
> > > From:	Doug Engert [SMTP:[email-masked]]
> > > Sent:	Thursday, November 06, 1997 6:41 AM
> > > To:	Mike Swift (NT)
> > > Cc:	[email-masked]
> > > Subject:	New draft coming your way
> > > 
> > > Mike Swift writes:
> > >  > I submitted a new draft last night, draft-ietf-cat-iakerb-00.txt,
> that
> > >  > specifies a protocol for using Kerberos and the GSS-API for initial
> > >  > authentication, such as in a dialup situation where there is
> > > connectivitiy
> > >  > available on the client. The general principal is that the client
> will
> > >  > create an AS request and rather than send it to the KDC, instead
> > > returns it
> > >  > from GSS_init_sec_context(). The client application sends the AS
> > > request to
> > >  > the service, which then forwards the request to a KDC and fowards
> the
> > > AS
> > >  > respons from the KDC back to the client. This allows use of
> Kerberos in
> > >  > situations where the client can't easily locate a KDC, such as on
> the
> > >  > Internet.
> > >  > 
> > >  > - Mike Swift
> > > 
> > > Interesting. Sounds like you are addressing the misuse of Kerberos by
> > > many of the firewall/terminal-server vendors. They require you to send
> > > your Kerberos password over the phone line to the concentrator who
> > > then authenticates you via Kerberos.
> > > 
> > > I have long said that this is backwards, the firewall should really
> > > allow you to send requests to the KDC before you are authenticated.
> > > (and maybe to DNS as well.)  Then you could use normal Kerberos
> > > authentication to authenticate to the firewall/terminal-server which
> > > would then give you full access to other addresses.
> > >  
> > > The "service" in your approach could be the firewall/terminal-server.
> 
> > > 
> > > -- 
> > >  
> > >  Douglas E. Engert  <[email-masked]>
> > >  Argonne National Laboratory
> > >  9700 South Cass Avenue
> > >  Argonne, Illinois  60439 
> > >  (630) 252-5444
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
>        [email-masked]                        PGP key available

---

From: Derek Atkins <[email-masked]>
Date: 07 Nov 1997 14:29:04 -0500

> about packetizing or being 6 bit clean. That encoding and packetizing can be

Actually, you still need to worry about packetizing and being 6- (or
at least 7-) bit clean.  You just moved that requirement to a
different level.  Sorry, but you can't shove it under the rug to make
it go away, you can only hide it until the rug gets moved.  If you
don't deal with packetizing and being transmittable, the application
that uses you will certainly have to do that.

If you can assume you have an 8-bit connection then I guess this isn't
important to you.  In my case I couldn't assume that control
characters would make it across a dialup session.

As for using the GSS-API, I could have made an interface between the
GSS-API and the Charon API, had the GSS-API existed in '93 ;) But that
is completely orthogonal to the underlying wire-protocol.

> required to the KDC to support this protocol. This makes a big difference

You are confused (or you didn't read my paper).  Charon requires no
changes to the KDC -- it only requires new client and server software.

> upgrading the KDC is often not a feasible option.

Agreed.

> requirements for authenticating to a dial-up server.

This is true...  Charon is a two-part protocol.  The first part is the
authentication of the user to the dialup server, and the second part
is obtaining a TGT on the dialup server.  You could easily skip the
second part so you just have authentication of the user to the dialup
server.

I chose to combine these two parts due to the requirements of the
original project, namely logging into a kerberized client machine via
dialup and retaining a TGT to use kerberized services from the login
server.  Looking back, a more general solution would have separated
the authentication to the login server from obtaining a TGT on the
login server.

-derek

---

From: Martin Rex <[email-masked]>
Date: Fri, 7 Nov 1997 22:59:37 +0100 (MEZ)

> requirements for authenticating to a dial-up server.

The functionality I expect to receive from Mike's proposed extensions
in the GSS-API framework is, that I may be able to access a
Server without direct IP-connectivity (e.g. across 2 or more firewalls)
with Kerberos protection just by replacing the gssapi implementation.

I'm really looking forward to this!

-Martin

PS: I'm not familiar with the lower level Kerberos protocols,
    Kerberos 5 is simply a GSS-API mechanism to our application.