Subject: Re: iTIP REPLY question

From: [email-masked]
Date: Tue, 6 May 2003 11:26:49 -0400

Doug replied on 04/24/2003 01:32:32 PM CST:
> > In CAP there is a CARID:REQUESTONLY VCAR to deposit METHOD:REQUEST
> > objects in another CUA's CS.
> > There is also the CARID:UPDATEPARTSTATUS VCAR to update PARTSTAT
> > information.
> > 
> > How do I get the rights to place METHOD:REPLY objects in another CUA's
> > CS?
> 
> They must give it to you in advance. If they have not given you the
> rights to deposit a REPLY into their CS, then they broke iTIP - ignore 
them
> and throw away the REQUEST.

Ahem, its not breaking iTIP if the CU1 did not grant CU2 the proper rights 
to return a response; its a user/configuration issue in CAP.  The 
REQUEST/REPLY bits are perfectly fine; its the VCARs the CU set that are 
at fault.

> It is possible that they want you to connect anonymously.

Are you suggesting that a CUA SHOULD try to connect and CREATE the REPLY 
and if that fails that the CUA change their identity to 'anonymous' and 
retry the command?  I would think that allowing 'anonymous' authenticated 
users to CREATE documents in a calendar would be less than desirable 
because there is no way to authenticate the identity against the contents 
of the message.  If I intercepted or guessed that you and John were having 
a meeting I could anonymously DECLINE on Johns behalf even though really 
ACCEPTed previously.  Hmm, sounds like potential for lots of hacker fun...

Anonymous access _is_ useful for public calendars or for "announcement" 
kinds of calendars but not for any serious C&S workflow because of the 
potential for hacking and disruption.

> > How do I access the other CS?
> 
> If the ORGANIZER property is a CAP uri, then open a connection
> to that uri.

Will this work for the case where CS's are behind firewalls and thus not 
necessarily exposed to external DNS servers? 

Can you at INET-consulting.com resolve my alice.iris.com CAP server? 
You'll probably get "Unknown host" from your DNS server.  So what should 
your CUA do at that point?

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Tue, 06 May 2003 10:17:52 -0600

[email-masked] wrote:
>  > rights to deposit a REPLY into their CS, then they broke iTIP - 
> ignore them
> Ahem, its not breaking iTIP if the CU1 did not grant CU2 the proper 
> rights to return a response; its a user/configuration issue in CAP.  The 

Your right.

> retry the command?  I would think that allowing 'anonymous' 
> authenticated users to CREATE documents in a calendar would be less than 
> desirable because there is no way to authenticate the identity against 
> the contents of the message.  If I intercepted or guessed that you and 
> John were having a meeting I could anonymously DECLINE on Johns behalf 
> even though really ACCEPTed previously.  Hmm, sounds like potential for 
> lots of hacker fun...

I am suggesting that it is an option. Within a company and inside
a firewall - why not?

> potential for hacking and disruption.

On the outside of a firewall - YES.

> Can you at INET-consulting.com resolve my alice.iris.com CAP server? 

If you set your ORGANIZER property value to CAP:alice.iris.com, I would
expect to be able to CAP reply to that address.

>  You'll probably get "Unknown host" from your DNS server.  So what 
> should your CUA do at that point?

I would call you on the phone and tell you you sent me a bogus
CAP object. Then delete the object from my store.

I do not see that it is any different than if you set your
ORGANIZER property value to mailto:[email-masked]. It
would bounce or not be sent when the MUA/CUA tried to look up the
MX record for alice.iris.com.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: [email-masked]
Date: Fri, 16 May 2003 09:54:13 -0400

Doug replied on 05/06/2003 12:17:52 PM:

Pardon the lag, I only can use my personal spare time these days to stay 
involved...

> I am suggesting that it is an option. Within a company and inside

Check the stats frequently cited in IT circles and the media:  not all IT 
threats come from without, MOST come from within!  You hear about external 
attacks because they cannot be covered up as easily; internal attacks are 
much much easier for a company to hush up.

If we worked at the same company and I had a grudge against you I could 
mess w/your calendar anonymously just because I can and because I didnt 
like the color of your hair (not true but for demonstration purposes lets 
say it is).  Or I decide to get some payback to those higher ups that got 
big bonuses this year while I got a pot luck lunch on the lawn. 

If I could _anonymously_ CREATE litterally hundreds or thousands of bogus 
DECLINEs I would eventually be able to get 'a hit' and easily cause you 
problems.  Maybe recoverble, maybe not.  The point is that there are no 
demonstratable cases where _anonymous_ users have the legit need to CREATE 
content in someone elses calendar.  After all, why would I want you to 
_anonymously_ authenticate w/my CS and then CREATE the ACCEPTance message 
in my calendar for a meeting that you were invited to?   You need to do 
this anonymously even though you were an ATTENDEE?...

I got news for you I will NEVER EVER allow anonymous access to my calendar 
for ANY PURPOSE (reading or writing!).  Wont happen and any sane user out 
there likely feels the same way.  There may be a case out there where its 
useful but I cannot think of one and I doubt most here can either. 

If this is a case of 99.99 to .01 Id say "margin of error" and toss the 
ability.  Then again we could probably say that an alternative means to 
this is to allow a CS to claim "its against CS policy to allow anonymous 
users to CREATE" and reject the command and assume CS developers think of 
this when they code 'em up...  Yeah, that sounds secure....

> On the outside of a firewall - YES.

Inside the firewall too!  We have internal servers set up as "bulletin 
boards" where folks can anonymously browse all kinds of information 
including montly calendars of events at sites, etc.  Reading from them can 
be done anonymously, putting content on them cannot.

> expect to be able to CAP reply to that address.

You are assuming that because my CUA was able to get outside the firewall 
and reach your CS somehow that your CUA MUST be able to both find and 
contact my CS to return the REPLY.  This is NOT necessarily true. 

Companys have few qualms about allowing outbound access by their people 
(ie: HTTP or SOCKS proxying) but they have cast in diamond (harder than 
stone!) rules against allowing external access to their internal networks 
let alone servers.  As such I would be able to reach your CS (assuming you 
allow access to your servers from outside your firewall!) but you have a 
snowballs chance in a nuclear blast of even getting the IP of my CS and 
reaching it from your CUA.

Unlike mail which has pretty well understood processes/needs and does not 
require exposing internal networks/servers directly to outsiders, CAP has 
an implic limitation that every CS involved must be directly reachable by 
the CUAs involved (remember, we took out 'fan out' and this is one side 
effect of that).  As such CAP only works as intended if companies expose 
their networks/servers and thats going to be a hard sell, especially to 
larger companies.

> CAP object. Then delete the object from my store.

Its NOT bogus!  It was perfectly formed and properly routed from my CUA to 
your CS.  Just because you cannot get to my CS does not mean the CAP 
object is bad!  If I had used a CS that is not valid (alice.iris.com is 
valid) or the data in the CAP object was bad then Id agree.  However its 
100% correct to EVERYONE ELSE who can reach my CS so how does that make 
the object bad?  If your CUA can process the REQUEST just fine then how is 
it bad?  Its not a problem w/the data; its a problem in the 
design/expectations.

> MX record for alice.iris.com.

Your mailer can lookup the MX record for iris.com and then send the REPLY 
to me there.  When it arrived at that server it knows how to reach 
alice.iris.com and off the REPLY goes again to the next hop or to 
alice.iris.com itself.

The comparison you use though is not that viable since mail is 
store/foreward and by defintiion CAP is point to point only.  Mail systems 
have all kinds of routing rules they can be configured with to get the 
message to the proper address.  CAP has nothing regarding this because all 
CAP is done CUA <-> CS and the CUA is responsible for contacting each CS 
in turn.

Bruce

---

From: John Stracke <[email-masked]>
Date: Fri, 16 May 2003 12:20:54 -0400

[email-masked] wrote:

> I got news for you I will NEVER EVER allow anonymous access to my 
> calendar for ANY PURPOSE (reading or writing!).

Agreed.

> Unlike mail which has pretty well understood processes/needs and does 
> not require exposing internal networks/servers directly to outsiders, 
> CAP has an implic limitation that every CS involved must be directly 
> reachable by the CUAs involved (remember, we took out 'fan out' and 
> this is one side effect of that).

Right.  As I recall, we took out fan-out in part because we didn't want 
to cope with the complexities of proxying requests with authentication.  
So we've replaced the difficulties of domain-to-domain authentication 
with the much larger difficulties of user-to-foreign-domain 
authentication.  Since this is a problem that's essentially unsolvable 
without a PKI, we've wound up with a mechanism that's unacceptable 
between domains, so people are going to have to drop back to 
email--where you still don't have any authentication, but at least your 
request has to look plausible to the user.

Actually, if we *require* the CUA to use the CS to do fan-out, we can 
get a fairly simple interdomain authentication mechanism.  If I get a 
message from a foreign CS, claiming to be from [email-masked] (never 
mind the syntax for now), I do the SRV lookup to verify that the source 
address is a CS for example.com.  (For an extra level of protection, I 
can actually connect to the CS specified in the SRV, and do some sort of 
cookie exchange to verify that I'm talking to the same entity that 
contacted me, instead of J. Random Process on the same host.) Now, in 
theory, it is possible for someone to crack the CS for example.com and 
send messages masquerading as [email-masked].  But, if they crack the 
CS, then they can do that no matter *what* authentication system we come 
up with.

This is an idea that came out of the IMPP discussions in 1999; the key 
point is that the owner of a domain is the ultimate authority on names 
allocated from that domain's namespace, and there is no point trying to 
gainsay that authority.  If I get a message that I can verify as being 
from the designated CS for example.com, and that designated CS asserts 
that the message is from [email-masked], that assertion is a tautology.

Of course, if you want assurances that a message is from a specific 
*person*, then you need a PKI; but this simple proxy authentication is 
good enough to prevent most types of spoofing (e.g., sending an ACCEPT 
that purports to be from [email-masked] but isn't), and to ensure 
accountability for spamming.  Better than iMIP, anyway.

-- 
/==========================================\
|John Stracke      [email-masked]   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|You buttered your bread, now lie in it.   |
\==========================================/

---

From: Doug Royer <[email-masked]>
Date: Fri, 16 May 2003 11:14:00 -0600

> calendar for ANY PURPOSE (reading or writing!). 

I think that is your point. Well CAP has anonymous UPS. So
your are debating policy and not protocol. Which is fine.

However your policy does not negate the issue. And they did
imply policy with their question.

So - yes you can do that. Many will not allow that.
Many public read-only calendar will however allow anonymous
access to view public calendars and many will not.

--

---

From: [email-masked]
Date: Fri, 23 May 2003 14:28:24 -0400

> access to view public calendars and many will not.

I know we agree on stuff, we've done it before and we can do it again...

So what about my other issues related to firewalls, inter/intranets, etc? 

Or the point about my REQUEST is NOT bogus because I was able to get it to 
your calendar just fine using CAP and you were perfectly able to read and 
parse it; the only problem was that you have no way to get back to my CS 
to respond...

Or the comparison between mail and routing vs CAP?...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 May 2003 13:39:03 -0600

> So what about my other issues related to firewalls, inter/intranets, etc?  

The issue was "can you" and "must you". The answers are "yes" and "no".

--

---

From: [email-masked]
Date: Fri, 23 May 2003 16:22:25 -0400

> The issue was "can you" and "must you". The answers are "yes" and "no".

I dont think you recall my original questions/comments Im referring to 
here so Ill repost them here to refresh everyones memory.  I had replied:

<SNIPPET>

</SNIPPET>

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 May 2003 15:09:42 -0600

[email-masked] wrote:
> ...
> You are assuming that because my CUA was able to get outside the 
> firewall and reach your CS somehow that your CUA MUST be able to both 
> find and contact my CS to return the REPLY.  This is NOT necessarily 
> true.  

It is true that you can send REQUEST objects and break them in such
a way that no one can reply. Don't do that. Such objects are bogus
and should be deleted. Just like a email with a bogus 'From' line.

Your example is not a valid comparison. My internal email address is
not the same as my world-known email address. And there is no
RFC or standard solution to the problem.

How do I get email replies? Because of a gateway that knows
what I did. And because I set my 'From' and 'Reply-To' to be
my world usable e-mail address and not my internal email address.
And that is not defined in any RFC. It is a vendor feature of many
vendor MUA's and gateways.

So, if you want to advertise CAP addresses, ether make a gateway
that translates for you, or only send out your world reachable CAP
address. Or make your CUA smart and send your local CAP address
to local users and your global CAP address to non-local users.

MX records are only used to find which system accepts [email-masked]',
it has nothing to do with if my internal e-mail address is reachable
from the outside. If I were to set my reply-to address to be my internal
e-mail address - all of my email would bounce. Just like with CAP
or iMIP.

--

---

From: [email-masked]
Date: Tue, 27 May 2003 11:49:20 -0400

> and should be deleted. Just like a email with a bogus 'From' line.

So the object that everyone inside my firewall can read, parse and 
understand just fine (as well as respond to)  is bogus because you have no 
way to send back a response...  This is not 'breaking' them so that "no 
one can reply"; its only a problem if you MUST be able to directly 
penetrate a firewall or other security cordon.

And just how is my CUA to know you cannot get back to me if it can reach 
you if it can reach your CAP server using something like SOCKSs?

I dont view this as an error with the data; I view this as a protocol 
limitation/problem.  After all the data itself is fine.  The _only _ 
problem seems to be that your CUA cannot find a route back to 
alice.iris.com using CAP...

> what I did. 

Not strictly true.  Your MUA does NOT use the routing info in the Received 
headers to follow any return path; it uses the Reply-To header and its 
configured SMTP server.  The MUA gives routing control over to the MTA and 
it handles getting the reply to the right place.  From RFC 2821 (SMTP):

   SMTP clients that transfer all traffic, regardless of the
   target domain names associated with the individual messages, or that
   do not maintain queues for retrying message transmissions that
   initially cannot be completed, may otherwise conform to this
   specification but are not considered fully-capable.

In CAP, the CSs do no such feature nor have we left any hooks for it in 
CAP 1.0.  EVERY CUA must perform the task of the MTAs and this makes CUAs 
either very complex or restricted to where they can do CAP (ie: only 
inside a firewall or only outside). 

In fact, SMTP has lots of text addressing 'relaying' that we never even 
consider in CAP 1.0 (an entire Section 3.7 even).  In any case the problem 
is NOT rooted in 'bad data' but in a weakness of the current design.

>          Or make your CUA smart and send your local CAP address

However we have no prose in CAP 1.0 around doing any kind of mapping 
between "local" and "non-local" CAP addresses.  In the email sense this is 
also handled by the MTAs but although CUAs are taking on the role of MTAs 
they have no guidelines for doing this bit either.

> from the outside.

All my MTA/MUA cares about is reaching royer.com.  How it gets from there 
to your 'internal' address is a function of sendmail really, NOT SMTP. 
Again from 2821, Section 5. Address Resolution and Mail Handling:

   If an SMTP server receives a message with a destination for which it
   is a designated Mail eXchanger, it MAY relay the message (potentially
   after having rewritten the MAIL FROM and/or RCPT TO addresses), make
   final delivery of the message, or hand it off using some mechanism
   outside the SMTP-provided transport environment.  Of course, neither
   of the latter require that the list of MX records be examined
   further.

One difference between the email and CAP analogies is that email is store 
and forward over possibly multiple hops whereas CAP is a real time PRC 
utilizing a strict point to point design.  The store/forward vs realtime 
is not that crucial (store/forward can done quickly enough to be a slow 
'realtime' action of sort).  The real factor is that email can be over 
multiple hops whereas CAP MUST be direct with no proxying or relaying 
involved. 

While adding full relaying in could take some time, if we had some hooks 
in CAP 1.0 that allowed a CAP 2.x CS to do relaying and for a CAP 1.0 CUA 
to unambiguously detect this then this issue could be fixable in a later 
version of CAP.  As it stands now, CAP 1.0 has no hooks nor clear means 
for expansion in this area going forwards and this should be at least 
looked considered for CAP 1.0.  I am NOT advocating that we delay CAP to 
put in full relaying features just that we put in some kind of hooks or 
prose to make CAP 2.0 easier...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 27 May 2003 11:32:54 -0600

[email-masked] wrote:
> understand just fine (as well as respond to)  is bogus because you have 
> no way to send back a response... 

I said no such thing.

 From this point forward I'll simply reply to technical questions
that have not already been answered.

--

---

From: [email-masked]
Date: Tue, 27 May 2003 14:50:46 -0400

> > no way to send back a response... 

I left your quote intact above and I see that it says "no one can reply" 
followed by "Such objects are bogus." 

So Ill restate my last response to see if its more accurate:

So the object that everyone inside my firewall can read, parse and 
understand jsut fine (as well as respond to) is NOT bogus just because 
only you cannot respond to it.  As such then whose fault is it that your 
CUA cannot respond? 

I claim that this is a weakness in CAP (dealing with firewalls, etc) and 
not an issue with iTIP!

Bruce
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Tue, 27 May 2003 13:26:06 -0600

> only you cannot respond to it.  As such then whose fault is it that your 

I have made no such claim.

--

---

From: [email-masked]
Date: Tue, 27 May 2003 15:57:48 -0400

> > no way to send back a response... 
In looking back in the archives a bit (just making sure I didnt totally 
misread your response) and I found that you actually did claim it was 
bogus. 

So you actually did claim that the iTIP message I sent that only you could 
not respond to was bogus.  This is not quite what you said later on (see 
top quote).

In any event the point of this thread was that CAP is really focused on 
CUA -> CS where the CUA is responsible for going to each CS in turn. 
However as I pointed out this is not always possible in a real world. 

This is not a problem in iMIP because the MTAs handle the routing/delivery 
rather than the MUA.  In CAP the CUAs take on the role of the MTAs and 
that can be a problem (especially if we have no clear hooks in CAP 1.0 to 
allow for CS fanout, etc going forward).  Its been said before but some 
folks seem to have forgotten it or do not think this is a possible 
problem.  Im not one of them though... 'Nuff said.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 27 May 2003 14:38:13 -0600

[email-masked] wrote:
> So you actually did claim that the iTIP message I sent that only you 
> could not respond to was bogus.  This is not quite what you said later 
> on (see top quote).

No Bruce. That is not what is says. The word 'expect' is in my quote.
And it is true: You can send bogus REQUEST objects and break them
in a way that no one can reply.

--