[4543] in Kerberos
Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
daemon@ATHENA.MIT.EDU (Dan Nessett)
Wed Feb 1 17:21:39 1995
Date: Wed, 1 Feb 1995 14:00:46 -0800
From: Danny.Nessett@Eng.Sun.COM (Dan Nessett)
To: Danny.Nessett@Eng.Sun.COM, jim@bilbo.suite.com
Cc: kerberos@MIT.EDU, cat-ietf@MIT.EDU
> From jim@bilbo.suite.com Wed Feb 1 12:12:25 1995
> To: Danny.Nessett@Eng (Dan Nessett)
> Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
> Cc: kerberos@ATHENA.MIT.EDU
>
>
> Dan Nessett writes:
>
> > It is the sequence number checks that will not work with
> > multi-threading.
> >
>
>
> I agree. The sequence number feature is too simple. One idea I've been
> thinking about would be to treat the sequence numbers more like
> timestamps. Each ticket could contain a set of "sequence" numbers (maybe
> as an initial random number and a count, or perhaps as a set of discrete
> random numbers) to use when securing messages via that ticket. This set
> would be known to both the client and the destination server. The
> destination server would save replay records just as it does for
> timestamped message, only these replay records would contain the
> "sequence" numbers rather than timestamps. The replay detection logic
> would have to be modified to not only compare the sequence numbers present
> in messages with those in replay records, but would also be smart enough
> to know which sequence number belongs to which ticket/set. It would take
> some doing, but it should be possible, after all, the destination server
> knows which ticket was used to secure the message.
>
> Jim_Miller@suite.com
>
Jim,
Well I have been thinking about something along these lines, but with a
difference. Since a ticket can set up a session that is very long lived,
I thought a window mechanism might be useful. The ticket would carry the
initial sequence number and a window value. Packets would be checked
to ensure their sequence number is within the window interval starting
at the current "low end" of the sequence numbers (which would originally
start at the isn). As packets arrive with sequence numbers above the "high
end" of the window, the window would shift, bringing the base sequence
number up to a larger value. If a packet arrives with a sequence number
outside of the window or if a packet arrives with a sequence number already
seen, it would be error flagged. Resynchronizing of sequence numbers would
occur when a new ticket was delivered.
Unfortunately, it is very hard to guess whether this sort of replay detection
would be appropriate for all apps. Consequently, I am currently of the
opinion that both GSSAPI and Kerberos should provide a way for an application
to provide a sequence number on a seal/mk_priv and sign/mk_safe call, as
well as return a sequence number on a unseal/rd_priv and verify/rd_safe
call and to set up the security context so the underlying mechanism doesn't
perform sequencing checks. This would allow the application to do its own
replay detection and sequencing in case the underlying mechanism's method
is inappropriate.
Dan
