Subject: draft-ietf-fax-service-v2-01.txt

From: Graham Klyne <[email-masked]>
Date: Wed, 12 Apr 2000 15:55:47 +0100

Folks,

I have some small comments.

>draft-ietf-fax-service-v2-01.txt
>A Simple Mode of Facsimile Using Internet Mail

>SUMMARY
>
>    This specification provides for "simple mode" carriage of facsimile
>    data over the Internet.  Extensions to this document will follow.

"over the Internet" seems rather vague.  I suggest "using Internet e-mail"

>1  SCOPE
>
>    This specification defines a message-based facsimile communication
...............................^
Delete "a".

>2.2.2     MIME
>
>    IFax devices MUST be compliant with MIME [4], except as noted in
>    Appendix A.

Do we want to say anything about support for multipart/alternative?  MIME 
technically requires this, but I understand it is not widely implemented.

>3.3 Address Formats Used by Offramps
>
>    When a G3Fax device is identified by a telephone number, the entire
>    address used for the G3fax device, including the number and offramp
>    host reference MUST be contained within standard Internet mail
>    transport fields, such as RCPT TO and MAIL FROM [1, 3].  The address
>    MAY be contained within message content fields, such as <authentic>
>    and <destination> [2, 3], as appropriate.
>
>    As for all Internet mail addresses, the left-hand-side (local- part)
>    of an address is not to be interpreted except by the MTA that is
>    named on the right-hand-side (domain).
>
>    The telephone number format SHOULD conform to [11, 12].  Other
>    formats MUST be syntactically distinct from [11, 12].

I find this is not clear.  What "other" is meant by "other formats"?  Does 
this refer to e-mail addresses that do not refer to GSTN-connected fax 
machines?

I also noted, looking at RFC 2304, that the address form:

     FAX=[email-masked]

is not permitted.  (i.e. no local-phone with FAX=)

I understand that the standard was not intended to say anything about 
non-standard forms.  But it's not clear to me whether the above example is 
just not-specified, or actually prohibited.

A possible replacement for the final paragraph quoted above:

# For fax machines that are accessed via a gateway to the GSTN, the address
# format SHOULD conform to [11,12], including a fully qualified international
# telephone number, per 'global-phone' [11].  For fax machines that are 
accessed
# by other means, including local dialing plans, address formats used MUST be
# syntactically distinct from the format defined by 'fax-mbox' [12].

>5.2.2     Resources consumed by dialout
>

[...]

>    Offramp gateways SHOULD provide the ability to authorize senders in
>    some manner to prevent unauthorized use of the offramp. There are no
>    standard techniques for authorization using Internet protocols.

What is the status of the SMTP AUTH specification?  Should it be cited here?

>5.2.5     Message disclosure
>
>    Users of G3Fax devices have an expectation of a level of message
>    privacy which is higher than the level provided by Internet mail
>    without security enhancements.
>
>    This expectation of privacy by G3Fax users SHOULD be preserved as
>    much as possible.
>
>    Sufficient physical and software control may be acceptable in
>    constrained environments.  The usual mechanism for ensuring data
>    confidentially entail encryption, as discussed below.
.........................^
"entails"

#g

------------
Graham Klyne
([email-masked])

---

From: Hiroshi Tamura <[email-masked]>
Date: Thu, 13 Apr 2000 18:51:07 +0900 (JST)

A question.

> is not permitted.  (i.e. no local-phone with FAX=)

FAX=[email-masked]

is permitted ?

RFC2304 says,
--------------------------------------------------------------------------
   global-phone = "+" 1*( DIGIT , written-sep )

   written-sep = ( "-" / "." )

   The use of other dialling schemas for PSTN numbers (like private
   numbering plans or local dialling conventions) is also allowed.
   However, this does not preclude nor remove the minimal compulsory
   requirement to support the "global-phone" syntax as defined above.

   Any non "global-phone" dialling schema MUST NOT use the leading "+"
   between the "=" sign and the dialling string. The "+" sign is
   strictly reserved for the standard "global-phone" syntax.

   Note:
     The specification of these different dialling schemas is out of
     scope for this minimal specification.
--------------------------------------------------------------------------

I am a little confused.

--
Hiroshi Tamura, Ricoh Company, LTD.
Mail: [email-masked]
Tel: +81-46-228-1743  Fax: +81-46-228-7500 (SUB/F-code 5727)

---

From: Graham Klyne <[email-masked]>
Date: Thu, 13 Apr 2000 11:22:59 +0100

Tamura-san,

Thank you for pointing out my error...

>FAX=[email-masked]

Yes, that's clearly OK.

>RFC2304 says,

I missed that -- thanks.

>    strictly reserved for the standard "global-phone" syntax.

And that!

>I am a little confused.

No -- it's my fault.  I looked at the ABNF, and not at the text.

Sorry to confuse you.

#g

------------
Graham Klyne
([email-masked])

---

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Fri, 14 Apr 2000 16:38:46 +0900

Klyne-san,

Thank you for your comments. 
I comment below.

>"over the Internet" seems rather vague.  I suggest "using Internet e-mail"

Yes, I agree.

>>    This specification defines a message-based facsimile communication

Thank you. 

>technically requires this, but I understand it is not widely implemented.

No, I think we don't need to say anything about support for 
multipart/alternative in this draft. It's enough that Implementer's Guide 
say about multipart/alternative.

>this refer to e-mail addresses that do not refer to GSTN-connected fax 

Other formats means private formats which don't conform to [11,12]. 
I want to keep this paragraph as it is.

>What is the status of the SMTP AUTH specification?  Should it be cited here?

I don't know the specification of SMTP AUTH.  I think that S/MIME or
PGP/MIME is needed for authentication and authorization rather than 
SMTP. 

Kiyoshi Toyoda

---

From: Brian Stafford <[email-masked]>
Date: Fri, 14 Apr 2000 08:57:38 +0000

> PGP/MIME is needed for authentication and authorization rather than

The provider of an offramp service needs to be assured of the identity
of the sender of the fax (presumably that's who gets the bill), not the
previous hop MTA.  This implies that the message itself must contain the
identity of the sender.  In a very simple case, the offramp operator might
have a database which maps sender email addresses to authorisation credentials.
A digital signature in the message will provide non-repudiation of the sender's
identity, within the limitations of the S/MIME or PGP concepts of trust.

Although the former case is wide open to abuse and forgery, it seems to
satisfy the statement that "Offramp gateways SHOULD provide the ability to
authorize senders in some manner to prevent unauthorized use of the offramp"
and avoids the need for normative references to S/MIME or PGP MIME.
Indeed any ad-hoc sender authentication would satisfy this requirement.

The second sentence "There are no standard techniques for authorization
using Internet protocols" diverts the reader's attention from authentication
of the fax message and its sender to the protocol which delivered the message
to the offramp. Perhaps the second sentence should be deleted to avoid
misleading the reader.

All that said, a standardised method to authenticate the sender of a fax would
be a good thing to have.

--
Brian Stafford, OfficeLogic International Ltd.
PGP fingerprint: 23DE 0A02 95B2 EC3C D521  0CD1 97D8 6BF2 B673 DC11

---

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Fri, 14 Apr 2000 20:29:28 +0900

>Indeed any ad-hoc sender authentication would satisfy this requirement.

I agree that there are some manner to prevent unauthorized use of the 
offramp and avoids the need for normative references to S/MIME or 
PGP/MIME.  S/MIME or PGP/MIME is one of the way.

Kiyoshi Toyoda

---

From: Graham Klyne <[email-masked]>
Date: Fri, 14 Apr 2000 13:23:52 +0100

>PGP/MIME.  S/MIME or PGP/MIME is one of the way.

A quick survey of RFCs reveals the following with relevance to SMTP and 
authentication.  (There may be others, including S/MIME and OpenPGP.)

2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman.
      January 1999. (Format: TXT=15120 bytes) (Status: PROPOSED STANDARD)

2554 SMTP Service Extension for Authentication. J. Myers. March 1999.
      (Format: TXT=20534 bytes) (Status: PROPOSED STANDARD)

2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses. R.
      Gellens. August 1999. (Format: TXT=16302 bytes) (Status: PROPOSED
      STANDARD)

#g

------------
Graham Klyne
([email-masked])

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Apr 2000 09:22:17 -0700

> > PGP/MIME is needed for authentication and authorization rather than

SMTP AUTH is gradually being deployed.  It does not yet seem to be widely 
available.  However, I agree that it is not the correct choice, for most 
fax-over-email.  SMTP is a "direct" mechanism, between the SMTP sender and 
the SMTP receiver, and SMTP AUTH therefore only works for one SMTP 
"hop".  However the originator of a fax-over-email and the gateway 
typically are separated by multiple SMTP relays (or "hops").

Therefore, security mechanisms based on wrapping something around the 
object, rather than around the relay channel, are appropriate.  So yes, PGP 
or S/MIME are the best choices.

>identity, within the limitations of the S/MIME or PGP concepts of trust.

In talking with my friends who are security experts, I find the use of the 
term 'non-repudiation" holds a special place.  Standard PGP and S/MIME 
mechanisms are adequate for "authentication" which validates that a 
signature is associated with a purported originator.  "Non-repudiation of 
originator" requires being able to prove to an independent third party that 
the signature is both valid and took place at a particular moment in 
time.  (That is, non-repudiation is designed to resolve a claim that the 
key used for the signature was compromised and that, therefore, someone 
else used it.)  There are no standard mechanisms for non-repudiation of 
originator for Internet mail, yet.

The existing mechanisms DO permit validating the identity of the purported 
originator.

>using Internet protocols" diverts the reader's attention from authentication

The problem is that authorization is a different mechanism from 
authentication.  A gateway does not only need to know who sent the fax but 
whether that sender is authorized to use the gateway.  There are no widely 
deployed authorization mechanisms for the Internet, although IMAP probably 
was the most widely used.

Hence a gateway and a fax originator must have some prior arrangement, 
using non-standard mechanisms.

It might be appropriate to change the text, to separate discussion of 
authentication from authorization, to avoid confusion.

>All that said, a standardised method to authenticate the sender of a fax would

Yes.  It would be wonderful.  Perhaps the new working group can explore 
this, although it is likely to be both difficult and beyond the basic scope 
of the new effort.  On the other hand, a store-and-forward email-based 
authorization standard would have much broader utility than just for use of 
outbound fax-over-email gateways.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

---

From: [email-masked]
Date: Fri, 14 Apr 2000 11:16:47 -0800 (PST)

> SMTP AUTH is gradually being deployed.

Actually, deployment has been quite rapid, on both the client and server side.
And there is every indication that this trend will continue and likely
accelerate.

This isn't because of FAX or any other "new" service. It is because of an old
problem: Spam. Most sites now implement anti-relaying policies. This in turn
means that in order to get access from outside the site to the site's relays
you have to use some kind of authentication. There are two ways this is being
done: SMTP-after-POP and SMTP AUTH. The former doesn't work in quite a few
cases (separate POP and SMTP servers, for example) and scales quite poorly. The
latter works quite well and, depending on the authentication scheme used,
scales well too.

So, once again we see that unless you have a true "killer app" your best bet on
getting a service deployed is to piggyback it on fixing  some pressing problem.
It isn't pretty, but it works.

> It does not yet seem to be widely
> available.

I don't agree.

There is one case where deployment is problematic, and that's where there's a
huge installed base of relative old clients with no good way to upgrade them.
But pressure to upgrade clients to the latest and greatest (which in almost
every case these days gets you AUTH support) is unrelenting because of other
factors. So this problem is likely to be transient even in such cases.

> However, I agree that it is not the correct choice, for most
> "hop".

Not true. Properly configured, the AUTH extension can carry authentication
credentials across multiple hops. This is what the AUTH MAIL FROM
parameter is all about.

> However the originator of a fax-over-email and the gateway

This is only a real issue when they are in separate administrative domains.
And there are other problems when this is the case -- problems you get
into below.

> or S/MIME are the best choices.

Both PGP and S/MIME have been around a lot longer than SMTP AUTH, yet
in my experience I see effectively zero deployment.

> using non-standard mechanisms.

This equates to having overlapping administrative domains. This in
turn means SMTP AUTH can be used.

Mind you, I'm not claiming that multi-hop SMTP AUTH is the best possible
mechanism to use for this sort of thing. But present-day reality is that
hop-by-hop security mechanisms are deploying quite rapidly. (The TLS SMTP
extension is deploying too, albeit not as rapidly since it doesn't have the
push of a problem behind it.) And end-to-end mechanisms, which have been around
a lot longer and have been advocated a lot longer, aren't.

I don't like this situation, but I'm a realist. I'd rather use something that's
there than wait for something that isn't there and I have no confidence ever
will be. Especially when I've already played the waiting game for over 10
years, with at least 5 different standards, and gotten nowhere.

				Ned