draft-bradner-pbk-frame-06.txt

[Randy Bush <randy@psg.com>]

an ops-dir reviewer points out some seemingly serious issues.

randy

---

The draft could do more to describe the limitations of PBKs.  For
example, my understanding is that there are significant performance
and denial of service concerns relating to them.

"It also scales well since the operations are confined to the end
systems involved in the communication."

The draft describes a protocol in which a Public/Private Key pair
is created on the Initiator, along with a PBID which is the hash of
the Public Key.  The PBID and Public Key are sent by the Initiator,
and bound to the source IP address by the Responder, after
verification of the Public Key -> PBID hash.  The Responder may
acknowledge receipt by including the PBID in an acknowledgement.

In a subsequent transaction, the Initiator sends a packet including
the PBID and a nonce or timestamp, and signs the packet using its
private key.

The Responder verifies the signature based on the public key
corrresponding to the PBID, then sends a random challenge to the
Initiator. The Initiator then signs the challenge with its private
key and sends the result to the Responder.

Since the protocol does not derive a symmetric key for future use
in providing per-packet integrity and encryption, it requires two
public key signature operations on the Initiator, and two public
Key signature verifications on the Responder per transaction.

This is probably too heavy weight for all but occasional
transactions, yet the draft states "The PBK mechanism is intended
to used with transport or application protocols."  Without deriving
a symmetric key, it is hard to see how it could be applied to say,
per-packet integrity or authentication operations.  Using PBK for
transport or application setup without deriving a symmetric key for
binding to subsequent packets would leave the connection vulnerable
to hijacking.  However, where transaction protocols are used there
is the issue of prevention of source address spoofing.  So it seems
to me that the authors need to talk about key exchange (so as to
enable binding of the PBK auth to subsequent packets for use with
connection-oriented protocols) and also DoS avoidance.

I'd also like to see more guidance about the hash from the Public
Key to the PBID.  In previous proposals, 64-bit hashes have been
proposed (e.g.  use as the IPv6 Interface Identifier), or perhaps
80 bits (16 bit subnet ID + 64-bit Interface Identifier).  What is
the minimum recommended hash size for this protocol?

The proposals for use of the PBID as an Interface Identifier have
always worried me, because they don't prove ownership of the source
address, only the Interface Identifier or Subnet-Id + Int. Id
portion of it, so that spoofing is still possible.  Perhaps a few
words about appropriate use (and abuse) of the PBID might be
appropriate.

" The PBK mechanism is susceptible to man-in-the-middle attacks
   which affect its initialization."

Essentially, in such an attack, an attacker substitutes their own
Public Key and PBID for those of the legitimate Initiator, causing
a binding to another host's source address to be plumbed on the
Responder.  After this, the attacker can impersonate the legitimate
Initiator.

"Therefore, the designer of such a protocol should be aware of this
risk and include a challenge- response confirmation step."

This sentence makes it seem like a challenge-response mitigates the
potential man-in-the-middle attack on the initial PBK-source
address binding step, but of course, it doesn't.  The attacker who
has convinced the Responder to accept its Public Key as legitimate
for a particular source address can also answer the Challenge
correctly. It might be better to say "In order to guard against
man-in-the-middle attacks on the initialization step, this step can
be carried out in a protected environment such as a physically
secure network. To mitigate a potential man-in-the-middle attack
after initialization, the designer of such a protocol..."

I'd also note that PBKs are susceptible to DoS attacks in that an
Initiator can get a Responder to do a Signature check, unless some
sort of DoS prevention/cookie mechanism is used.  A 3 or 4-way
transport connection handshake can be helpful in this regard, and
of course it also provides some assurance that the source IP
address is correct and with it, the PBK to IP address binding. In
transaction protocols I am not clear how this level of assurance
can be provided. And as noted earlier, in connection-oriented
protocols, some sort of symmetric key derivation seems necessary to
prevent hijacking.  So there are some substantial limitations on
useful application of PBKs.

Some of the issues involved in preventing DoS attacks on PBK
protocols are discussed here:

http://research.microsoft.com/users/tuomaura/Publications/aura-roe-arkko-acsac02.pdf