Subject: IESG Comments on draft-ietf-trade-voucher-lang-05.txt and proposed changes

From: Ko Fujimura <[email-masked]>
Date: Mon, 16 Feb 2004 19:46:17 +0900

Hello IETF trade list,

We received comments from the IESG on the draft as attached.
To incorporate these comments,  I updated the draft and posted,
today.  So, the updated draft (-06) will be announced in couple
of days.

Major changes from the previous version (-05) are as follows:

(1) We agree with IESG comments on the <Conditions> elements
(See attached) and now we changed it not to allow sub-elements.
We rewrote Section 6.11 <Conditions> as follows:

   The <Conditions> element contains any other restrictions or
   conditions applied. This is intended to cover contracts between the
   issuer and holder of the voucher in natural language form.
  
   An implementation of a wallet system SHOULD provide a means of
   displaying the text in this element.

   The <Conditions> element has no attribute.

   The <Conditions> element is defined by the following schema:

    <element name="Conditions" type="string"/>

Similaly, we added the use of the <Merchandise> element to Section 6.9
as follows:

   This element is intended to be interpreted by a collecting system.
   An implementation of a wallet system does not have to use this
   element. Any restrictions applied should also be described in the
   <Description> element or the <Conditions> elements in natural
   language form to enable users to check the restrictions.

(2) We think that more descriptions are need to clarify the role of
Voucher Component and VTS regarding security. We rewrote Section 9
"Security Considerations" as follows:

   The VTS must provide a means of preventing forgery, alteration,
   duplicate-redemption, reproduction of a voucher, and non-repudiation
   of transactions as described in Section 3.2 of [VTS]. These security
   requirements, however, mainly follow the VTS plug-ins and their
   protocols. This document assumes that the VTS plug-ins are trusted
   and installed by some means, e.g., manually checked like other
   download applications.

   The Voucher Component, however, defines restrictions on VTS Provider
   (or VTS plug-in), and if this information is altered, incorrect VTS
   plug-ins not accepted by the issuer could be used, and a forged
   voucher could be verified as if it were valid. To prevent this
   situation, the Voucher Component should be acquired securely, e.g.,
   downloaded from a trusted party using a secure communication channel,
   such as [TLS], or [IPSEC], or secured by the digital signature of a
   trusted party.

(3) It is not to incorporate IESG comments but we added a registration
request for the vts-lang name space in Section 7 "IANA Considerations"
for consistency with other related documents.

In the previous draft (-05), the name space
"urn:ietf:params:xml:schema:vts-lang" was used. Now (-06), it is
changed to "urn:ietf:params:xml:ns:vts-lang" for consistency with other
similar works
(See http://www.iana.org/assignments/xml-registry-index.html).

That's all. I think these changes cover comments pointed out by IESG.
Please let me know if you have any additional comments.

Regards,

Ko

IESG Comments on draft-ietf-trade-voucher-lang-05.txt:
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6624&rfc_flag=0>

 >===============================================================================
 >The security discussion is inadequate.  Do you need channel security (TLS,
 >IPsec) or object security (XMLDSIG)?  I suspect that the latter is more
 >applicable, but in either case, an analysis is necessary to demonstrate
 >why.  If either can be used, guidance should be provided on when each
 >type should be used. What security services are necessary? 
Confidentiality?
 >What if the voucher is from an embarrassing organization? Integrity?
 >PRobably.  Non-repudiation?  In that case, object security is needed.
 >But who checks for replays, and how?
 >
 >===============================================================================
 >Frankly, I have general problems with the scope of this work; it seems to
 >need a much tighter applicability statement (given that they are defining
 >a "Voucher Component and VTS-API specifications" but not a standard
 >protocol). 
 >
 >I also think this needs a good bit more review by folks who might have
 >to use it, as a lot of seems to be based on assumptions that might or 
might
 >not hold true generally. A good example of this is in the "Conditions"
 >processing (sections 4 &  6.10).  The initial description of the 
Conditions
 >in section 4 says:
 >
 >  Condition Component
 >
 >    Provides any other applicable restrictions. This is intended to
 >    cover contracts between the issuer and holder of the
 >    voucher in natural language form.
 >
 >"Natural language form" implied to me "free text" as opposed to
 >"structured text", but the  description in 6.10 says:
 >
 >  The <Conditions> element may contain any element used to specify
 >  any other restrictions or conditions applied that limit the use of
 >  the voucher. The sub-elements contained in this element are
 >  depending on the application of the voucher and are left to the
 >  other domain-specific specifications. Domain-specific elements can
 >  be extended as sub-elements using [XML-ns].
 >
 >That seems to imply that <Conditions> can be structured in certain 
contexts,
 >but that the structure there might relate only to the context, which 
leaves it
 >a bit up in the air as to whether someone getting a voucher needs to 
preserve
 >markup here.
 >
 >The last line related to <Conditions> is:
 >
 >  If the <Conditions> element is omitted, it will be generally
 >  interpreted that there are no other restrictions or conditions on
 >  using the voucher.
 >
 >If the structure of this is application dependent, the interpretation 
of this
 >pretty much has to be as well.  There is no way to prevent someone from
 >saying "in my application, no conditions will mean there are no conditions
 >under which you can use this".  If this is retained, it seems like it 
has to be
 >given as deployment advice, rather than a default configuration.
 >
 >===============================================================================
 >The Security Considerations are not sufficinet.  They say:
 >
 >   Security issues for delivering Voucher Components are discussed in
 >   Section 3.
 >
 >Section 3 says:
 >
 >   The Voucher Component is usually delivered from the trusted VTS
 >   Provider, Issuer or trusted third party using a secure
 >   communication channel, such as [XMLDSIG], [TLS], or [IPSEC].
 >   Delivery of the Voucher Component is beyond the scope of this
 >   document.
 >
 >Since the specification of secure communication channel has been
 >declared out of scope, the Security Considerations should explain
 >the consequences of not using a secure communication channel.
 >
 >===============================================================================
 >

--------------------------------------------------------------
Dr. Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)46-859-3814, Fax: +81-(0)46-859-8329
Email: [email-masked]

---

From: Masayuki Terada <[email-masked]>
Date: Thu, 19 Feb 2004 22:04:33 +0900 (JST)

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 <[email-masked]>
    Security Systems Lab., NTT DoCoMo Multimedia Labs.