[4551] in Kerberos
Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
daemon@ATHENA.MIT.EDU (Dan Nessett)
Thu Feb 2 11:49:59 1995
Date: Thu, 2 Feb 1995 08:35:45 -0800
From: Danny.Nessett@Eng.Sun.COM (Dan Nessett)
To: linn@cam.ov.com
Cc: jim@bilbo.suite.com, kerberos@MIT.EDU, cat-ietf@MIT.EDU
John writes:
>
> A desirous application is completely free to set up and manage whatever
> sequencing and/or replay detection scheme it seems appropriate and
> represent the corresponding sequence numbers, timestamps, or other
> data elements within its tokens. Such application-managed data would
> be uninterpreted by GSS-API or Kerberos; it would just be a part of
> the token and doesn't need to be visible as a distinguished item at
> the interface. The only conflict potential I can see would arise
> if the application were layered atop a mechanism which performed its
> own sequencing and/or replay detection (in a conflicting fashion)
> even when the caller requested that these optional services not
> be enabled for the context. RFC-1508 strongly recommends that
> mechanisms honor a caller's request to disable the message stream
> integrity services on a per-context basis; if mechanisms honor
> this recommendation, I think a pure application-level approach,
> wholly independent of GSS-API and Kerberos, should "just work" today.
John,
Your suggestion that applications could place sequence number data within
their own messages is a valid workaround, given the existing interface.
In fact, while exploring the gssapi code in the MIT Kerberos distribution
it appears to me that sequence number checking is not carried out by either
verify() or unseal(), so the application is going to have to do this for
the existing implementation anyway.
[ the bit of code I am looking at is in k5unseal.c and it is the comment :
/* XXX this is where the seq_num check would go */
NB: both verify and unseal call the routines in k5unseal.c]
However, I think someone else has said during the discussion of this issue that
sequencing is a security service and is naturally part of the services that
would be offered by GSSAPI. While I would not suggest changing the existing
definitions, I think it is appropriate to consider adding a way to get
consistent and useful sequence number / timestamp checking using the interfaces
being developed for GSSAPIv2.
This is why I suggested adding something to the seal/unseal/sign/verify
[or whatever their new names will be] that allows the application to pass
in sequence number or timestamp data that will be included in the associated
tokens. The advantage is it relieves the application programmer from defining
a field in the application protocol messages to carry what might be considered
"lower layer" data. For example, if the sign/seal routines allowed the
application to pass in an opaque 64-bit quantity and verify/unseal returned
this quantity, then the application could use it for sequencing (whether
it carried sequence number or timestamp data).
I am not ready to draw swords on this suggestion, I merely mention it as a
possibility. As someone who will be using GSSAPI, I always can use the
workaround you described. However, the GSSAPI interface MUST then have a
way for the application programmer to specify that NO sequence number or
timestamp checking should be carried out. Otherwise, the mechanism will
report errors when none exist (e.g., in the multi-threading cases I have
mentioned in previous messages).
Dan
