GSSAPI - context lifetime

[Machin, Glenn D]

> What about key usage though?  The obvious advice here
> is: use AES.  But what should the mechanism do when the key
> is 1DES and
> the app is doing bulk, high bandwidth data transfers?


I don't think that this is something that wrap/unwrap needs to be concerned with. First only the application can determine how much data will be moved during the session. Then if you change the behavior of the code based upon the key type, you could create all sorts of confusion to the end user.  My gssftp of 2 large files works from system A to system B but not from system A to system C, all because A to B used AES and A to C used DES.

I agree that the strongest key should be negotiated between the initiator and acceptor. Allowing the initiator or acceptor to limit the types negotiated would be beneficial. But once the context is established don't change the behavior.



Glenn





> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams at sun.com]
> Sent: Friday, May 30, 2008 10:29 AM
> To: Machin, Glenn D
> Cc: Douglas E. Engert; 'krbdev at mit.edu'
> Subject: Re: GSSAPI - context lifetime
>
> On Fri, May 30, 2008 at 10:08:09AM -0600, Glenn Machin wrote:
> > It appears that Heimdal sets the context lifetime to that
> of the ticket,
> > but ignores it in wrap/unwrap.   GSS_S_CONTEXT_EXPIRED is a possible
> > return value so I don't know if this is in violation of the RFC.
>
> Note: the RFC in question would be 4121, since RFC2743 does
> mandate that
> GSS_S_CONTEXT_EXPIRED be used.  RFC4120 and RFC3961/3962 would be the
> places to look for key lifetime.
>
> RFC4121 says nothing about context expiration and RFC2743 doesn't have
> enough text from which to guess what the right behaviour would be for
> any one mechanism.
>
> Therefore implementors are left to guess what to do here.  It's not
> surprising that two implementors chose different behaviours.
>
> >  From the discussion on this email thread its clear that
> the checking of
> > the context lifetime in wrap/unwrap is a usability issue.
> >
> > So can we just ignore the context lifetime in the
> wrap/unwrap?  It seems
> > to me that would have less of an impact to applications.
>
> I support this.  What about key usage though?  The obvious advice here
> is: use AES.  But what should the mechanism do when the key
> is 1DES and
> the app is doing bulk, high bandwidth data transfers?
>
> Nico
> --
>
>