[4544] in Kerberos
Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
daemon@ATHENA.MIT.EDU (Jim Miller)
Wed Feb 1 18:38:48 1995
From: jim@bilbo.suite.com (Jim Miller)
Date: Wed, 1 Feb 95 17:22:23 -0600
To: Danny.Nessett@eng.sun.com
Cc: kerberos@MIT.EDU, cat-ietf@MIT.EDU
Reply-To: Jim_Miller@suite.com
Dan Nessett writes:
> 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.
>
I can see how your window mechanism would work.
Just for grins, here's an expanded description on the idea in my previous
post.
Each ticket would describe a range of sequence numbers using an initial
random number and a message count. In this way a ticket would be "good
for" a certain number of messages, in addition to being valid a certain
length of time.
Client Side:
Each time a client sends a message, it would get the "next number" from
the ticket (credential, actually) and use it as the message sequence
number. If the "next number" > (initial number + message count), then the
client would have to get a new ticket.
Server Side:
Server receives the message, decodes/decrypts it and examines the endtime
of the appropriate ticket. If the ticket has expired, then the message is
rejected (i.e. Messages secured using these kinds of sequence numbers
would expire when the ticket used to secure them expires.). Assuming the
ticket has not expired, and the other checks pass, the server examines the
sequence number. The sequence number must fall within the range of
numbers described in the ticket used to secure the message (duh).
To cut down on the amount of replay information that would have to be
searched, the server maintains a number (N) indicating the lowest number
in the range below which all numbers have already been received.
Hmm, that doesn't sound very clear. Assume that all sequence numbers from
"initial number " through N have arrived. Now, if a message comes in with
a sequence number < N you don't have to search through the replay cache to
know its a replay.
So, instead of simply searching the replay cache, you first compare the
message's sequence number with N. If the sequence number <= N you know
its a replay. If the sequence number is > N, you search the replay cache.
If a replay record exists that contains a matching client, server, and
sequence number, then the message is a replay. The replay cache search
will also tell you when it is time to increment N.
My N is kind of like your sliding window, but it only tracks the lower-end
of the window.
Finally, the replay cache expunge code could be modified to remove records
with sequence numbers < N. Of course, this implies the various Ns
associated with the tickets are somehow stored in the replay file. I have
an idea on how to do this, but I don't feel like going into details in
this post.
> 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
>
Agreed. Both scheme require the server to save state information in the
replay cache. If the client and server are relatively simple
applications, then the current stateless sequence number scheme is
adequate.
Jim_Miller@suite.com
