[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compare-jfk-sigma.txt
This is a good point, Angelos!
Let me take this opportunity to say that there is no need at all
for R to sign message 1 (but only include the nonce sent by I
under its own signature).
The way I see the question of what should be signed is as follows:
a party should sign (i.e include under its own authentication) ALL the
information it sends PLUS freshness information from the peer (such
as a nonce).
The motivation for this is that each party needs to verify that ALL the
information it received was really sent by the peer, and is fresh, i.e.
generated in this run of the protocol and not replayed from a previous
one.
SO I do not recommend a too selective signing as done in IKEv1 and JFK
(which may leave unauthenticated information in the protocol -- as
actually happens in IKEv1), and I do not recommend Tero's hash where EVERY
bit in the protocol (regardless of who sent it) is signed, but rather the
middle way where each party signs everything she sent plus the peer's
nonce. (For example, signing everythingin IKEv2 or SIGMA would lead to
everyone signing the peer's ID which has no security advantage,
and has some privacy disadvantages).
BTW, there is another reason not to go for a "sign message 1 and message
2" as in IKEv2: if you do that then the security of the protocol depends
on what exactly you sent in these messages. As an example, if one sends
g^i in the third message of the protocol (this makes sense if the
responder does not keep state anyway after message 1) then the protocol
becomes INSECURE since the signature of I on g^x is fundamental for the
security of the protocol.
[Note that g^i in msg 1 serves also to tell R what is the prefered
group by I, but if R does not keep state then it would be sufficient
for I to send in msg 1 a simple group descriptor rather than 1Kb+
of DH exponential].
If, instead, each party signs all the information she sent then it is
guaranteed to include g^x regardless of the message where it was sent.
Hugo
On Mon, 10 Dec 2001, Angelos D. Keromytis wrote:
>
> In message <OFD54EE6B3.71026D64-ON85256B1B.00120DA4-@85256B1B.0018C53CLocalDoma
> in>, Charlie_Kaufman@iris.com writes:
> >
> >The one remaining difference is the choice of bits being signed. The
> >protocol
> >above signs selected fields from the messages, while IKEv2 proposes
> >signing the entirety of messages 1 and 2 as they appear on the wire. (and
> >the entirety of all future messages are integrity protected, so all fields
> >in all messages are integrity protected.) The advantage of the
> >IKEv2 approach is that it captures all relevant fields in the messages
> >including
> >any extensions like vendor IDs. It's also easier to specify, since the SIG
> >above will have to specify exactly how the bits are encoded for signing
> >(TLV vs raw; payloads with or without headers, etc).
>
> Doing so for messages 1 and 2 would require keeping state at the responder
> on receipt of message 1.
> -Angelos
>
Follow-Ups:
References: