Re: iTIP REPLY question

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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...

> >  > 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...
> 
> I am suggesting that it is an option. Within a company and inside
> a firewall - why not?

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....

> > 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.
> 
> 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.

> >  > > 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? 
> 
> 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 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.

> >  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.

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.

> I do not see that it is any different than if
you set your
> ORGANIZER property value to mailto:bruce@xxxxxxxxxxxxxxx It
> would bounce or not be sent when the MUA/CUA tried to look up the
> 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
===========================================================================
Bruce Kahn                  
             INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...