Subject: Re: IRIP version 4 (Part 2) a

From: [email-masked] (Steve Mansour)
Date: Thu, 25 Mar 1999 08:13:50 -0800

Paul & Bob -- there some security issues/concerns midway through this, I
believe we've talked about them, but now others are beginning to
notice...

[email-masked] wrote:

> Continued from section 3.2 Fanout and Queued Transactions
>
> Under 3.1.9 SWITCH:
>
>   There are a few references to the "greeting message" but there is no
>
> clear description of it or its format.  Is it like IMAP or POP3 or
> just a
> reply code or some arbitrary text sequence??

Thanks for pointing that out. In early versions of the draft, there were
arbitrary text strings after the response code. Those have since been
removed, but the text to which you refer was not properly updated.

I've fixed it.

> Under 3.2 Fanout and Queued Transactions:
>
> >A trusted relationship between two IRIP servers means that one server
>
> >can queue transactions for the other server and deliver them some
> time
> >later. If IRIP server B trusts A, then A can queue requests for B. If
> A
> >does not trust B then B cannot accumulate requests for A.
>
> Why cant there be a queue between non-trusted hosts?

we should allow this ----with appropriate provisos

> This happens for
> stuff like SMTP mail so what is wrong w/it here?  Affraid for data
> integrity?  Some other motiviation?

Yes, data integrity and other similar security concerns. Someone could
impersonate as an Organizer and reek havoc on events or todos. All the
standard iTIP security concerns apply here.

We should probably make it possible for non-trusted hosts to queue
messages. But we must make it clear that there are more security
concerns with non-trusted hosts.

We do have things like S/MIME and PGP/MIME that people can use to
protect their data.

> >In IRIP the reply code to the RECIPIENT
> >command indicates whether or not a reply will be made in real-time.
> >This allows the sender to abort the request if necessary.
>
> Upon further reflection I dont think this is 100% guaranteed.  For
> example,
> Server A establishes a link to Server B to do fan out and reflects
> this in
> its RECIPIENT reply code.  The sender then begins to send ICALDATA.
> In the
> mean time, Server B goes down (or the link to it is lost, etc).  There
> is
> now no way that Server A can return a real-time reply apart from
> saying
> "Sorry but Ive had to queue this up for Server B".

Yes that is true. Another thing Server A can do is fail the operation to
server B (that is, there is no requirement for Server A to queue
something if Server B fails).  But I will change the wording here to
reflect the possibility of error you point out.

> Under 3.3 Bi-Directional Queue Operation:
>
> Another example of why 2 servers may not be able to immediately
> establish a
> session is that the admin has configured some policy to prevent this.
> For
> example, in some European countries a modem connection may be long
> distance
> and they want to restrict these kinds of connections to being at night
>
> only.  As a result, the requests get queued until evening before being
> pass
> along; there may be no intermediate 3rd host.
>
> >The firewall in
> >front of B.foo.com prevents external connection on the IRIP server
> >port. Similarly, the firewall in front of D.bar.com also prevents
> >connections on the IRIP server port.
>
> Be sure to clarify that the firewalls are prohibiting INBOUND iRIP
> connections, not OUTBOUND.  Otherwise you would need to be using some
> protocol proxy as well (ala SOCKS).

fixed.

> >A trust
> >relationship between the intermediate IRIP server and the endpoint
> >servers (B.foo.com and D.bar.com) is desirable but not required.
>
> This conflicts w/your original assertion above that I already
> challenged...

agreed. we should stick with "desirable but not required".

> Hmm, just what would prevent server katt.pcweek.com from
> authenticating to
> the server C.foobar.com and then doing DEQUEUE irip://B.foo.com/...
> and
> sucking down data that it should not have access to?

First of all, let's be clear on the security risk here. The calendars on
irip://b.foo.com/ are not at risk. What is at risk are queued iTIP
messages on irip://b.foo.com/ that are targeted for calendars on
irip://katt.pcweek.com/.  Nothing else. Second, if a trust relationship
between irip://B.foo.com/ and irip://katt.pcweek.com/ exists, the basis
of that trust relationship is that if someone has authenicated as having
rights to a calendar on irip://katt.pcweek.com/ then they should be able
to dequeue iTIP messages for that calendar.  This is the risk with
allowing irip servers that don't have trusted relationships perform a
DEQUEUE.

I have had customers tell me that they are interested in deploying this
sort of arrangement behind their firewall. In the case they describe,
security is not a risk, and setting up a trusted relationship is
overhead they would prefer not to deal with.

> There seems to be no
> restriction or control over what CALID a sender can DEQUEUE to in the
> queueing model.  Am I missing something or did noone else notice this?

No, we noticed this! We have not adequately described how someone
authenticates to a calendar store. That is why Paul Hill believes we
will have to introduce the notion of a Calendar User into IRIP (I
brought this up at the ietf meeting). But *IF* you have authenticated to
iRIP Server A and *IF* it believes you have "iTIP" rights to a calendar
(say, irip://A/bill) and *IF* there is a trusted relationship between
the iRIP servers A and B, then you should be able to DEQUEUE messages
for irip://A/bill that have been queued on irip://B/.

Again, the risk in allowing queuing between non-trusted IRIP servers is
that the first two *IF* clauses above are not true.

> Under 3.4 Reply Codes:
>
> >In addition to those defined in [ITIP], [IRIP] defines the following
> >error codes:
> [Snip]
> >2.0    STATOK                  Operation was successfully performed.
>
> Actually, isn't 2.0 already defined in iTIP?  (Its not new to iRIP.)

Yes. This is a big problem. On one hand, it's hard to tell people to
refer to a bunch of different drafts/rfcs and piece together a reply
code list. On the other hand, if they're all in one place, people say
we're duplicating errors already defined.

Suggestions?

> >2.0.4 WILL-ATTEMPT             The specified Calendar is not here
> >                               but An attempt will be made to deliver
>
> >                               the request or reply to the Calendar
> >                               anyway. There is a trust relationship
> >                               between this IRIP server and the
> >                               IRIP server for the target calendar.
> >2.0.5  TRUSTED-WILL-QUEUE      The specified Calendar cannot be
> >                               contacted directly and a trust
> >                               relationship exists between this
> server
> >                               and the server on which the Calendar
> >                               exists. The request or reply will be
> >                               queued and delivered to the target
> >                               calendar when its IRIP server contacts
>
> >                               this server and issues the SWITCH
> >                               command.
> >2.0.6  WILL-ATTEMPT            The specified Calendar is not here
> >                               but an attempt will be made to deliver
>
> >                               the request or reply to the Calendar
> >                               anyway. The
>
> The meaning of 2.0.4 and 2.0.6 are the same.  Looks like some
> oversight in
> the editing process or merging of some comments.

NOW I REMEMBER WHAT THAT DANGLING "The" was for!  Must have gotten
interrupted before I had a chance to finish that sentence. There is a
very subtle difference between 2.0.4 and 2.0.6  -  2.0.4 signals an
attempt between two iRIP servers that have a trust relationship.  2.0.6
signals an attempt between two iRIP servers that do not have a trust
relationship.

I've clarified this in the reply codes.

> The descriptions for these  reply codes explicitly indicates that
> there is
> a trust relationship or not w/the remote host.  Does this need to
> really be
> done?  If so, then we need to have some 'non-trusted' equivalents!

well... if we're all in agreement that we should allow queuing for
non-trusted hosts, we'll need to add a reply code -- then non-trusted
equivalent of 2.0.5

> There appears to be some missing text for the last part of 2.0.6; the
> dangling The.

already got it :)

> >8.3    DATE TOO LARGE          A DATETIME value was too large to be
> >                               represented on this Calendar.
>
> Make this more generic to be more like "Date out of Bounds" to
> indicate
> that a DATETIME value was before the MINDATE of the server or after
> its
> MAXDATE (since these are now required capabilities).  ("Too large"
> implies
> > MAXDATE or you are a Un*x programmer).  You could then merge it with
> 8.4
> which has a better description.

I agree with the bad description on DATE TOO LARGE. I've fixed up the
description to indicate that it is too far in the future to be
represented. I still like separating the two errors. It's a little more
granular, and it doesn't really cost anything to do.

> There is no 10.3 reply code but there is a 10.4 and 10.5.  What
> happened to
> is?  If its gone, move 10.5 down to be 10.3, otherwise add it back
> into the
> table.

It was probably there at one point, then it got yanked.

> I dont have iCal handy to refer to it but does:
> >10.1   REFERRAL                Accompanied by an alternate address.
> really belong in the 10.x class of reply code?  Isnt it more appropo
> to be
> in the "FYI" category rather than a "Severe error" category (ala 10.4
> Quota
> exceeded)?

You want to suggest an error number for REFERRAL ?   :-)

---

From: Bob Mahoney <[email-masked]>
Date: Thu, 25 Mar 1999 11:56:44 -0500

>believe we've talked about them, but now others are beginning to

Well, noticing is good...  :-)

> > >A trusted relationship between two IRIP servers means that
> > >one server can queue transactions for the other server and
> > >deliver them some time later. If IRIP server B trusts A , then
> > >A can queue requests for B. If A does not trust B then B
> > >cannot accumulate requests for A.
> >

I assume this means we evaluate those queued requests for access 
rights in some way before execution?

>standard iTIP security concerns apply here.

Working with "strangers", in any scenario, is where security gets 
complicated...  :-)

>concerns with non-trusted hosts.

One of the classic security threats is flooding a server with 
requests for action, such that no legitimate works gets done.  We'll 
want to think about non-trusted hosts, and (try to) make sure someone 
can't simply destroy your server's functionality by pretending to be 
a previously unknown host that suddenly has 6 million bogus requests 
for you to process.

>We do have things like S/MIME and PGP/MIME that people can use to

I been having some conversations with folks here and in the WG on 
this area.  I'm going to write it up in some understandable fashion 
today. and get it to the list.

>overhead they would prefer not to deal with.

Just a small comment on this point: Don't make assumptions about the 
security inside your firewall...

Most security challenges, whether at banks or computer sites, 
originate on the "friendly" side of the locked doors and firewalls.

Customer perceptions have been greatly influenced by firewall hype. 
A nice write of of the "3 Myths of Firewalls" can be seen at 
http://web.mit.edu/kerberos/www/firewalls.html

Our protocols should be secure on their face.  Customers can always 
disable security features they don't want to deal with, but we can't 
assume that firewalls will exist, or that they will actually protect 
Cal data.  ("Firewalls are security icing, not security cake.")

I've fallen way behind on the list, in my post-IETF backlog, but I'm 
working to get current.   More stuff coming...

-Bob