[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heimdal and r* client programs





Nicolas.Williams@ubsw.com wrote:
> 
> Actually, Simon's patches do reference the Heimdal and MIT krb5 APIs in addition to GSS-API, specifically for credentials handling (i.e., writing out ccaches) and account authorization (i.e., krb5_kuserok()). But aside from that Simon's patches use GSS-API and, in any case, work with Heimdal and MIT.

True. But thats a lot simpler. 

As a side note: With regards to the handling of the delegate credential,
The Global Grid Fourm is trying to address that, with extensions to the GSSAPI.
One of these is gss_export_cred. 

 See:   http://www.gridforum.org/2_SEC/GSI.htm
 and    http://www.gridforum.org/security/ggf4_2002-02/draft-ggf-gss-extensions-05.pdf

The authorization checks by krb5_kuserok still needs to be addressed. 

> 
> Cheers,
> 
> Nico
> --
> 
> > -----Original Message-----
> > From: Tillman Hodgson [mailto:tillman@seekingfire.com]
> > Sent: Thursday, August 15, 2002 3:16 PM
> > To: Douglas E. Engert
> > Cc: heimdal-discuss@sics.se
> > Subject: Re: Heimdal and r* client programs
> >
> >
> > On Thu, Aug 15, 2002 at 01:34:15PM -0500, Douglas E. Engert wrote:
> > > Tillman Hodgson wrote:
> > > > I'm more interested in the built-in supports for kerberos
> > v5 in the ssh
> > > > version 1 protocol. I'm trying to move away from hand-rolled ssh
> > > > packages to ease maintainence issues :-)
> > >
> > > Yes and so am I!
> > >
> > > Simon's excellent mods to OpenSSH implement the IETF ssh
> > working groups GSSAPI
> > > authentication
> > > protocols. See:
> > http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-04.txt
> > > The draft is close to being adopted. Hopefully the OPenSSH
> > people will then
> > > add Simon's mods to their distribution, addressing your
> > comment about maintenance issues.
> > > Since they are using the GSS-API, so you don't deal with
> > MIT or Hiemdal API issues either.
> > > So using the GSSAPI is about as standard as you can get.
> >
> > Sounds great! Avoiding the API mess would be great. I suppose
> > that until
> > the patches become mainstream, I only need to roll a custom
> > package for
> > a single perimeter machine - and that's reasonably maintainable.
> >
> > Speaking of different interfaces, the kadmin differences
> > between Heimdal
> > and MIT is biting me. I have a RedHat Linux 7.3 box with the MIT krb5
> > RPM's installed and I'd like to kerberize it's services. To
> > do this, I'm
> > going to need a keytab. Unfortunately, it appears to me that kadmin
> > stuff isn't interoperable. Is there another way to get a
> > working keytab?
> >
> > I had thought that if I created the host principal with a
> > known password
> > that I might be able to use the MIT ktutil's add_entry
> > command to create
> > the appropriate keytab, but all I get from add_entry is a usage
> > statement regardless of what arguements I pass it.
> >
> > - Tillman
> >
> > --
> > Waking a person unnecessarily should not be considered a
> > capital crime.
> > For a first offense, that is.
> >       - Robert Heinlein
> >
> 
> Visit our website at http://www.ubswarburg.com
> 
> This message contains confidential information and is intended only
> for the individual named.  If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail.  Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
> 
> E-mail transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses.  The sender therefore
> does not accept liability for any errors or omissions in the contents
> of this message which arise as a result of e-mail transmission.  If
> verification is required please request a hard-copy version.  This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities or
> related financial instruments.

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444