A small problem in security protocol

In many protocols under academic discussion (like NSPK protocol,
Big-mouth-frog protocol, etc) there is no an apparent field in some
messages that shows which step in which protocol this message is and
who is the sender of this message, is it a problem?

I got this problem for if there is no such a tag, it will bring a
problem that when one agent receive a message in the protocol, how does
he know use which key in his own private key and other agents' public
(maybe decades or even hundreds) to decrypt the message like message 1
in NSPK protocol in an environment where many different protocols and
multi instances of same protocol are executed at the same time. It is
impossible to try each key for most asymmetric key cryptograph
algorithms are highly resource-cost.

Considering the case in Woo Lam mutual authentication protocol of
missing the sender's identification:
1. P -> Q : P, N1
2. Q -> P : Q, N2
3. P -> Q : {P, Q, N1, N2}Kps
4. Q -> S : {P, Q, N1, N2}Kps, {P, Q, N1, N2}Kqs

When Q get message 3 being encrypted by Kps which is a shared key
between P and S and Q didn't know it, consider multi instances of this
protocol are carry out at the same time, how does Q know this message 3
is from P and compose the second half part of message 4 using P's ID in
{P, Q, N1, N2}Kqs? And further considering in a multi protocol
environment, Q may even doesn't know message 3 is a message in Woo Lam
mutual authentication protocol.

Maybe this problem of showing the sender of message can be resolved
easily by adding the sender ID in the message, but will it bring new
security problem to the protocol? If the protocol analysis won't
consider the situation of multi protocol environment, is it right and
won't there be an attack scheme of cross-protocol attacking?

Re: A small problem in security protocol

wt.eric@gmail.com wrote:
> In many protocols under academic discussion (like NSPK protocol,
> Big-mouth-frog protocol, etc) there is no an apparent field in some
> messages that shows which step in which protocol this message is and
> who is the sender of this message, is it a problem?

As a general answer (I'm not familiar with the protocols in question):
yes. This is a potential DoS attack vector. If an attacker can inject
messages into the stream, they can knock the state machines out of sync.
Even worse attacks, e.g. session hijack, could be possible if the
protocols aren't designed against it.

That's why many protocols carry cookies or nonces as a security feature.

-- Lassi

Re: A small problem in security protocol

Thanks for your response. Maybe I hadn't made a clear description. My
problem is that: when an agent receives an encrypted message (signature
message we assume here), without apparent fields of message sequence
number in protocol and sender's ID, how does he rapidly get know which
message in which protocol this message is and which keys should he use
to decrypt the message.

Lassi Hippeläinen wrote:
> wt.eric@gmail.com wrote:
> > In many protocols under academic discussion (like NSPK protocol,
> > Big-mouth-frog protocol, etc) there is no an apparent field in some
> > messages that shows which step in which protocol this message is and
> > who is the sender of this message, is it a problem?
>
> As a general answer (I'm not familiar with the protocols in question):
> yes. This is a potential DoS attack vector. If an attacker can inject
> messages into the stream, they can knock the state machines out of sync.
> Even worse attacks, e.g. session hijack, could be possible if the
> protocols aren't designed against it.
>
> That's why many protocols carry cookies or nonces as a security feature.
>=20
> -- Lassi

Re: A small problem in security protocol

wt.eric@gmail.com wrote:
> Thanks for your response. Maybe I hadn't made a clear description. My
> problem is that: when an agent receives an encrypted message (signature
> message we assume here), without apparent fields of message sequence
> number in protocol and sender's ID, how does he rapidly get know which
> message in which protocol this message is and which keys should he use
> to decrypt the message.

If the message has no cleartext hints about sender/session, the
recipient has to try each active security association to see which one
matches. That is bad. It puts lots of computational load on the
recipient. An attacker can send bogus packets to overload the recipient.

BTW, modern protocols try to do the opposite. To initiate a session the
other end has to compute a "puzzle" before the recipient dedicates any
resources to the negotiation. That way the attacker can't overload the
machine unless she has an even bigger machine.

-- Lassi

> Lassi Hippeläinen wrote:
>> wt.eric@gmail.com wrote:
>>> In many protocols under academic discussion (like NSPK protocol,
>>> Big-mouth-frog protocol, etc) there is no an apparent field in some
>>> messages that shows which step in which protocol this message is and
>>> who is the sender of this message, is it a problem?
>> As a general answer (I'm not familiar with the protocols in question):
>> yes. This is a potential DoS attack vector. If an attacker can inject
>> messages into the stream, they can knock the state machines out of sync.
>> Even worse attacks, e.g. session hijack, could be possible if the
>> protocols aren't designed against it.
>>
>> That's why many protocols carry cookies or nonces as a security feature.
>>
>> -- Lassi
>