A Framework for Purpose-Built Keys (PBK)
draft-bradner-pbk-frame-06

After several nudges, there has been no action since July 2003.  Therefore, I am moving this document to the 'Dead' state due to lack of interest.  The authors can resubmit if they become interested again.

Comments from ops dir.

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-acsac0
2.pdf

Comments during telechat:

Ted Hardie:

In the draft, the Introduction says:

  When this mechanism is used with applications the PBK's public key
    can be used in an identity for a web-cookie like function, but the
    use is under the control of the node that initiates the connection
    rather than under the control of the server.


I'm not sure what is meant here.  HTTP cookies create pseudo state,
and a mechanism like this is pretty heavyweight for that use.
Note that the use of cookies for identification is rarely appropriate;
essentially only when there is an identity-based state and no
authentication
or authorization is required.

In the Informative References, this seems to be a strange format:

    ([Syverson] is just a good starting point) as well as work that has
    kinship to the pseudonyms in this in this work [Brands], [Chaum88],
    [HIP], [SUCV].


Russ:

  Please spell out first use of AAA.

  Section 1.0 says:

    By not using registered keys, the PBK mechanism preserves user
    pseudonymity as long as the identities of the users are not obtained
    by some other process during the communication.

  s/obtained/disclosed/

  Section 1.0 also says:

    The PBK mechanism is susceptible to man-in-the-middle attacks which
    affect its initialization. Such attacks may make it possible for a
    pseudonymous identity to be used by a party other than the issuer.
    There is an "initial leap of faith" about the pseudonymous identity
    since it has no parties, other than the issuer, vouching for it, and
    though only the issuer holds the private key, a man-in-the-middle
    attacker may appear to hold and use the identity without good care
    being taken in a protocol design that makes use of PBK. ...

  I think that "issuer" is the wrong term.  To me, the term "issuer" has
the wrong connotation.  I think you mean the party that generated the
public/private key pair and then sent it to the recipient.