Subject: Re: [MSEC] draft-blom-mm-kmgt-00.txt

From: Ran Canetti <[email-masked]>
Date: Mon, 27 Aug 2001 01:16:11 -0400

Here are some more remarks I had (in addition to Mark's) on the two drafts
that were presented in the msec meeting in London: 

draft-blom-mm-kmgt-00.txt 
draft-carrara-mm-kmgt-sol-00.txt

(Reminder: In a show of hands following a discussion following the presentation,
there seemed to be clear consensus to take up these drafs in msec.)

Best,

Ran

Generally, I liked the clear and concise way in which both drafts were
written. the requirements draft is especially an improvement over other key 
management protocols (both unicast and multicast) where the requirements are 
not clearly stated. Still, I have a number of questions and remarks: 

* First, a general remark: Although it is not stated explicitly in the 
requirements document, all your key-exchange protocols seem to assume that the 
two parties are time-synchronized and the protocols are based on timestamps for
freshness. This indeed simplifies the protocols and reduces the number of
rounds. But it puts much trust in the timing mechanism. Is this a concious
choice? In particular:
  -What is the accuracy (or time-window) that you had in mind for the parties
  to accept a received timestamp as "fresh"? 
  -Do you think that this time window can be both wide enough to allow for
  reasonable interoperability and narrow enough to avoid attacks?
These are serious questions that should be answered per scenario.  

Note that most other ietf-standardized key exchange protocols (ike,ssl,ssh)
dont use a timestamp mechanism. instead they use random nonces for freshness. 
This makes the protocol more complex (more state, more flows) but it also 
makes for more robust protocols. 

* Regarding the requirements draft:
1) There are a couple security concerns that are missing in the requirements 
document. One is anonymity (ie, identity protection) against a passive
eavesdropper. Is this a concern for you? if so, do you want to protect the 
identity of the initiator? responder? both?
A related concern is identity protection against an active attacker that
impersonates one of the parties. For instance, assume an attacker
impersonates an initiator and interacts with a responder for the sole
purpose of obtaining the identity of the responder. a similar attack can be
mounted against an initiator. Is this a concern for you?
(It is impossible to protect both the initiator and the responder against
such an active attack, at least when standard techniques are used. But 
it's possible to protect one of the two, by making sure that the other party
reveals its identity first. Typically, it is better to protect the identity
of the client, who is typically the initiator. 

Are you willing to pay in number of rounds and complexity to satisfy these
concerns?

2) I'm confused about your description of the SIP setting, where some
intermediaries need to be given access to certain fields in the packets, and
the statements that this limits the end-to-end security of the key exchange.
I'm not familiar with the workings of the SIP protocol, but does this protocol
prevent a completely end-to-end KE protocol where the cryptographic payload
is strictly contained in the message fields than need not be accessed by
intermediaries? ie, is there an inherent contradiction to end-to-end
security or is it just a technicality that can be overcome?

* Some remarks regarding the protocols draft:
(Other remarks can be postponed to a later stage.)

1) the protocols do not seem to protect against DoS attacks. 
A standard technique to mitigate the problem is to use a
cookie-response mechanism, where the responder makes sure that there is a
"real party" out there before it engages in expensive public-key operations
or starts to maintain state. the current protocols dont do that - the responder 
engages in those expensive activities right after receiving the first
message (which could be replayed arbitrarily, within the same time unit).

Adding the cookie mechanism would result in one more round-trip.
(In fact, one more flow may be enough). Did you weigh one against the other?

2)  Only one of the protocols (the DH one) provides forward secrecy (PFS). 
Indeed, the computational cost of this protocol is the highest.
Is forward secrecy a concern for you? is it worth the extra cost?
this should be discussed. possible outcomes may be to either mandate it 
(as IKE did) or leave it optional (as SSL did) or decide it is not a concern 
and leave it out. 

3) Pre-shared key mode: Hashing the key k_m in B's response is a bad idea.
It ruins the security of the protocol since it potentially provides the
attacker with a way to verify whether some guesses regarding the potential 
value of k_m are correct. A more robust cryptographic practice (and one that
can be proven secure) is to first derive a special key k_a from k_m,
and then have B send PRF_{k_a}(ID_a || ID_b || T), where PRF is a
pseudorandom function, or a MAC function. This way the security of k_m 
remains intact against such guessing attacks.

This remark holds also wrt the public-key encryption mode.

4) PKE mode: the identity of the sender, IDa, must always be included in the 
encrypted stringin A's message. Otherwise the first message 
may potentially be replayed by an attacker.

5) Similarly, in the DH exchange, the recipient's identity must be included
in the signed text in both flows. Otherwise some spoofing attacks may be
possible.

6) The draft whould provide guidelines regarding key lifetimes and
the rekeying procedures. When should a key expire? after an amount of data
encrypted? time elapsed? combination of both? can that be a parameter
decided in the session setup?
also, do you enforce one type of rekeying only? note that if no PFS is
necessary in the rekeying process then it is possible to rekey without any 
additional communication. (Each party locally derives a new key from the old
one, say using the usual key derivation method.)

* Finally, both drafts seem to concentrate on the unicast case and only very
briefly sketch the 12M/M2M cases. This is ok, 
since we have to solve that case first. but please bear in mind that the move 
to the one-to-many (or even one-to-few) case is a considerable step, which 
requires a somewhat different appeoach and tools. It does not necessarily 
have to be much more heavyweight, but it's quite different. In particular, 
a couple questions that you may want to think about:

 - Do you want to have a "group membership controller" that is different
   than the data source? Or do you think of the data source as inherently
   the same entity as the membership controller?

 - Do you want to deal with dynamic membership, ie people join and leave
   during the lifetime of the group, or do you want to deal only with groups
   where the membership is constant throughout the lifetime of the group?
   (or alternatively where receivers join but there is no
   backwards-access-control requirement)?