RE: Some Text on Security

At 12:18 PM -0800 3/31/99, Larry Osterman (Exchange) wrote:
>Ok, I'll try sell it.  HTTP-DIGEST is a SASL-ized version of the HTTP DIGEST
>authentication mechanism.  As such, any server/client software that has
>support for HTTP authentication will already have logic in it that's
>suitable for packaging up for HTTP-DIGEST.  It's my understanding that a
>bunch of the IETF protocols are moving to DIGEST as their must-implement
>authentication mechanism.  The only other competing mechanisms that I'm
>aware of are:

It might be useful for folks to review Keith and Patrik's draft, "On 
the use of HTTP as a Substrate for Other Protocols"  It's at:

http://www.ietf.cnri.reston.va.us/internet-drafts/draft-iesg-using-http-00.txt

A lot of really relevant information, in a nice format.  It discusses 
HTTP digest, TLS, Firewall transversal, and a lot of other 
terms/ideas we'll be tossing about.  

-Bob

Re: Some Text on Security

"Larry Osterman (Exchange)" wrote:

> It's my understanding that a
> bunch of the IETF protocols are moving to DIGEST as their must-implement
> authentication mechanism.

When I was at Netscape, Everyone Knew that http-digest was insufficiently
secure.  I don't know details, unfortunately; it was something that everyone
said our security people had said, but I never heard it from our security
people.  Anybody know more?

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|francis <at> ecal.com|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Re: Some Text on Security

At 4:15 PM +0000 4/1/99, John Stracke wrote:
>
>When I was at Netscape, Everyone Knew that http-digest was insufficiently
>secure.  I don't know details, unfortunately; it was something that everyone
>said our security people had said, but I never heard it from our security
>people.  Anybody know more?

One snippet from Keith & Patrik's document:

----
2.3 Security

     Although HTTP appears at first glance to be one of the few "mature"
Internet protocols that  can  provide  good  security,  there  are  many
applications  for which neither HTTP's digest authentication nor TLS are
sufficient by themselves.

     Digest authentication requires a secret (e.g.  a  password)  to  be
shared  between  client  and  server.   This  further requires that each
client know the secret to be used with each  server,  but  it  does  not
provide  any  means  of  securely  transmitting such secrets between the
parties.  Shared secrets can work fine for small groups  where  everyone
is physically co-located; they don't work as well for large or dispersed
communities of users.  Further, if the server  is  compromised  a  large
number  of  secrets may be exposed, which is especially dangerous if the
same secret (or password) is used for several applications.

     TLS is  descended  from  SSL,  which  was  originally  designed  to
authenticate servers to clients - not the other way around.  Even though
TLS now provides mutual authentication, a client that needs to  talk  to

Re: Delimiter characters in relativeCalUID

There are many problems with using a '/' were used to represent a
calendar hierarchy.
In fact, imposing any semantic definition to unique identifier has many
problems.

Here are some problems using a '/' to represent calendar hierarchy:

1) Force the server designer to use a specific calendar hierarchy.

It imposes a folder like hierarchy of calendars similar to file
diretories.
If the designer used a database for storing calendars, there is no
meaning to the slashes.  Calendar hierarchy should be specified ONLY
through the parent and child-list properties.

2) Exposes the calendar hierarchy to clients.

The server may not want to expose the calendar store's hierarchy just to
allow access to a calendar.  However, if a '/' was used to meaning a
level of hierarchy, then I would have to expose the entire path to allow
access to a calendar.

Suppose calendar "ghi" is a child of calendar "def",
which is a child of calendar "abc".

Thus the URL to access calendar "ghi" would be

    http://calendar.x.com/abc/def/ghi.

The URL exposes the hierarchy of calendar "ghi" to the user.

Re: Delimiter characters in relativeCalUID

RE: Some Text on Security

However the same statements made below can be made about ANY of the MTI
authentication mechanisms that have been discussed, and in general are the
same for every shared secret authentication mechanism.

I don't think that it is appropriate to discard http-digest simply because
it's a shared secret authentication mechanism, it's "good enough" to pass
IESG muster, and that should be sufficient.  HTTP-DIGEST does have
vulnerabilities, however the vulnerabilities derive directly from the fact
that it's simple to implement, and in reality the simple to implement
criteria is overwhelming in a MTI authentication mechanism.

There is nothing that prevents a more secure SASL mechanism from being
deployed by a vendor, neither is there a requirement that a CUSTOMER not be
allowed to turn off the MTI mechanism (if the customer percieves it as being
insufficiently secure).  The customer SHOULD be notified that disabling the
MTI mechanism may cause interoperability issues, however that's ultimately
the customers decision.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

-----Original Message-----
From: Bob Mahoney [mailto:bobmah <at> mit.edu]
Sent: Thursday, April 01, 1999 8:19 AM
To: John Stracke
Cc: ietf-calendar <at> imc.org
Subject: Re: Some Text on Security

At 4:15 PM +0000 4/1/99, John Stracke wrote:
>
>When I was at Netscape, Everyone Knew that http-digest was insufficiently
>secure.  I don't know details, unfortunately; it was something that
everyone
>said our security people had said, but I never heard it from our security
>people.  Anybody know more?

One snippet from Keith & Patrik's document:

----
2.3 Security

     Although HTTP appears at first glance to be one of the few "mature"
Internet protocols that  can  provide  good  security,  there  are  many
applications  for which neither HTTP's digest authentication nor TLS are
sufficient by themselves.

     Digest authentication requires a secret (e.g.  a  password)  to  be
shared  between  client  and  server.   This  further requires that each
client know the secret to be used with each  server,  but  it  does  not
provide  any  means  of  securely  transmitting such secrets between the
parties.  Shared secrets can work fine for small groups  where  everyone
is physically co-located; they don't work as well for large or dispersed
communities of users.  Further, if the server  is  compromised  a  large
number  of  secrets may be exposed, which is especially dangerous if the
same secret (or password) is used for several applications.

     TLS is  descended  from  SSL,  which  was  originally  designed  to
authenticate servers to clients - not the other way around.  Even though
TLS now provides mutual authentication, a client that needs to  talk  to
multiple  servers  must  still know which credentials to present to each
server before establishing a secure connection to  the  server.   Client
and  server  must  each  use  private keys that are trusted by the other
party - typically because they are signed  by  a  certificate  authority
(CA)  known  to  the  other.  As in the digest authentication case, both
client and server need  ways  to  protect  their  private  keys  against
exposure.
----

Re: Delimiter characters in relativeCalUID

John Sun wrote:

> Here are some problems using a '/' to represent calendar hierarchy:
>
> 1) Force the server designer to use a specific calendar hierarchy.

No, it doesn't.  If you don't want a heirarchy, you just make sure you
don't have any '/'s in your calendar IDs.

> 2) Exposes the calendar hierarchy to clients.

Aliases.

Again, I am not saying we should *use* the '/' in CAP1; I just want to
reserve it (or some other character) for use in a hypothetical future
version.  Otherwise, CAP1's calendar IDs will gobble up the entire
namespace, and there won't be any safe way to build a string that
delimits them.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|francis <at> ecal.com|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Re: Delimiter characters in relativeCalUID

John Stracke wrote:

> John Sun wrote:
>
> > Here are some problems using a '/' to represent calendar hierarchy:
> >
> > 1) Force the server designer to use a specific calendar hierarchy.
>
> No, it doesn't.  If you don't want a heirarchy, you just make sure you
> don't have any '/'s in your calendar IDs.

The only concern I would have about making that sort of a claim is that it
will cause interoperability problems for mixing and matching clients and
servers. For example, one client thinks that the '/' means hierarchy. The
server it talks to assigns no special meaning to '/'.

> > 2) Exposes the calendar hierarchy to clients.
>
> Aliases.
>
> Again, I am not saying we should *use* the '/' in CAP1; I just want to
> reserve it (or some other character) for use in a hypothetical future
> version.  Otherwise, CAP1's calendar IDs will gobble up the entire
> namespace, and there won't be any safe way to build a string that
> delimits them.

This is a slippery slope. Either they are an opaque string or they are
not.  If we start by making it an opaque string and add semantics later we
will almost certainly encounter problems.

-Steve

Re: Delimiter characters in relativeCalUID

Steve Mansour wrote:

> OK. Let's put this point to the test. Should we introduce one or more delimiter
> characters into relativeCalUID or should it be an opaque string?  Speak up.
>

Maybe I'll get the last word on this subject :)

I looked over rfc 2396 (defines URI) and it already recommends the following:

- Reserved Characters (see section 2.2)
- Unreserved Characters (see section 2.3)
- Excluded US-ASCII Characters (see section 2.4.3)

Note that "/" is in the list of recommended reserved characters and <CR><LF> in
excluded characters. It also mentions that these lists of reserved characters,
unreserved characters, and excluded characters as well as hierarchy and case
sensitivity are left up to the definition of the URI schemes.

As Bruce pointed out, I think there is a good argument for definining this grouping
of characters (reserved, unreserved, and excluded) for both iRIP and CAP. This will
allow for simpler URI parsers and avoid interoperability problems between
implementations. As for charset, this rfc says "in the simplest case, the original
character sequence contains only characters that are defined in US-ASCII" and that
"it is expected that a systematic treatment of character encoding within URI will
be developed as a future modification of this specification. Using the KISS
philosophy, we should stick to the US-ASCII charset for our URI schemes.

As for delimiter characters, this is not needed since we already have parent/child
properties of a calendar. As Doug pointed out, it is a security hole to allow
parent/child relationships in URI names, which bypasses the security checks that
protect the parent/child properties of a calendar.

We should not confuse the publishing of calendars as documents (or files) with
referencing calendars in iRIP or CAP. In a document URI scheme like http://, it
makes sense to navigate a file system using the URI name. However, it would be a
mistake to imply that an iRIP or CAP server implements a file system hierarchy for
navigating it's calendars. More than likely, these servers will use databases to
store these calendars. If a client needs to discover it's children or parent, it
should request and receive (subject to access control) the calendar properties
associated with the URI.

I propose that the iRIP and CAP editors tighten up their definitions of
relativeCALID to include a list of reserved characters, unreserved characters, and
excluded characters, to specify US-ASCII as the only charset for relativeCALID, and
that no hierarchy or case sensitivity is required in a relativeCALID.

Richard

Re: Latest CAP examples available on IMC Website

As Steve points out, examples are a good way to flush out issues. If this WG
hopes to have a useable draft of CAP by the next IETF meeting, we need to
flush out more issues and create more examples. Here is a partial list of
examples that I think we (as a WG) need to post:

- AUTHENTICATE anonymously
- AUTHENTICATE as a specific user
- Get CAPABILITY of a CS
- (already posted) CREATE VCALENDARs with RELCALUIDs
- (already posted) CREATE VCALENDARs without RELCALUIDs
- CREATE VEVENT across multiple VCALENDARs
- CREATE a VCAR in a VCALENDAR
- DELETE VCALENDAR
- DELETE VEVENT
- DELETE VEVENT properties
- READ VCALENDAR to obtain a list of all top level VCALENDARs
- READ VCALENDAR properties for a VCALENDAR
- READ VTIMEZONEs for a VCALENDAR
- READ VCARs for a VCALENDAR
- READ the parent and all the children of a VCALENDAR
- (already posted) READ VEVENTs for a specific time range
- READ VEVENT for a specific UID
- READ VEVENTs that have a VALARM for a specified time range
- MODIFY VCALENDAR properties
- MODIFY the ATTENDEE properties in a VEVENT
- MODIFY the DTSTART and DTEND properties of a VEVENT
- MODIFY an inline ATTACH property
- MODIFY a single recurring VEVENT
- CANCEL, ABORT, and DISCONNECT

Sometime next week, I hope to post my attempts at some of these examples.
Any other volunteers?

Steve Mansour wrote:

> Folks,
>
> Thanks to Paul Hoffman, we now have a repository for our CAP examples:
> http://www.imc.org/ietf-calendar/cap-examples/
>
> The latest versions of the examples are posted. Alex Taler helped with
> adding comments and cleaning them up. I'll update this site
> periodically.
>
> I hope we can add a lot more soon. It seems like this is a good way to
> flush out issues with everyone's involvement.
>
> If you have any examples you'd like to propose (or better yet, type up),
> please send them to the list.
>
> -Steve