IESG Comments on draft-ietf-trade-voucher-vtsapi-05.txt and proposed resolutions

[Masayuki Terada <[e-mail]>]

Hello trade WG list,

We received the following comments on the draft from IESG:

> The security API is inadequate.  It doesn't support things like
> challenge/response, it doesn't support cryptography, it makes no
> provision for the client to authenticate the server (we've already
> seen fake server attacks in the wild; this threat isn't
> hypothetical), it doesn't seem to have a way to convey a user name,
> it doesn't have the right primitives to support TLS, etc.
> 
> The document uses the domain foo.bar in examples rather than the
> domains reserved for such purposes: example.com and example.org.

Of course, security is very important for trading vouchers, and it
must be provided by a VTS (plug-in).  VTS-API is intended to provide
well-abstracted and unified semantic primitives for user (and wallet)
to interact with such a VTS.

And also, I believe that VTS-API provides enough primitives for VTS to
support security, like challenge/response needed in distributed VTS.
We have implemented and demonstrated a voucher wallet (and
issuing/collecting) system with a smartcard-based VTS implementation
at the 54th IETF Yokohama.

The previous draft (-05), however, could have too simple explanation
about securing VTS implementation.  To address the concerns from IESG,
we revised the draft based upon the following considerations:

1) About supporting challenge/response

VTSAgent#prepare() may be used to get a challenge from the receiver of
a voucher (see 5.4.3).  After invoking prepare(), the sender's VTS
plug-in may create the corresponding response and send it to the
receiver by VTSAgent#transfer() (or issue/consume/present), which
(logically) rewrites the ownership of the voucher in the VVS.

The description in the previous draft (-05), however, could be too
simplified and misleading as if the rewriting were always performed
physically upon the central database (in a centralized VTS
implementation).  In the revised draft (-06), we described more
explicitly that the rewrite is logical and it may be performed by
sending the response (corresponding to a challenge) in a distributed
VTS implementation.

2) About supporting cryptography

VTS should support cryptography, but cryptography algorithms/protocols
used in a VTS (e.g. in challenge/response) should be determined by the
provider of the VTS, not a user (of the wallet).  Cryptography should
be encapsulated in a VTS and doesn't appear in the API.

For similar reason to 1), we described explicitly that cryptography
should be used to secure the challenge/response or the authentication
of the user in VTSAgent#login().

3) About provision for the client to authenticate the server

I supposed that this comment discusses client/server authentications
of the centralized VTS implementation in 5.4.1 VTSAgent#login(), since
"server" only appears there in the previous (-05) draft.

In a centralized VTS implementation, a client (i.e. the VTS plug-in)
can be assumed to know the server's address and the authentification
information (e.g. the public key certificate of the server) in a
preference file or a smartcard.  a VTS may use them to prevent fake
server attacks.

However, I agree that it would be better for VTS providers to warn the
fake server attacks in the draft.  Some implementation notes are added
in 5.4.1 VTSAgent#login().

4) About having a way to convey a user name

I'm not sure what this comment would point out, but we add some
comment lines about usernames to the example code.

5) About having the right primitives to support TLS

VTS-API doesn't provide specific primitives to support TLS by same
reason as 3).

However, TLS would be useful and should be recommended to secure
communication channels such as those connect between clients and the
server in a centralized VTS implementation.  TLS is recommended as a
means to secure communication channels in the revised draft.

6) About domain names in the example.

It's my mistake; fixed as the comment.

-----

I believe that the changes made in the revised draft would address all
of the comments from IESG, however, I'd appreciate additional comments
or suggestions if any.


Best regards,

    Masayuki Terada <[e-mail]>
    Security Systems Lab., NTT DoCoMo Multimedia Labs.