Subject: i know you don't want to hear it but

From: "David L. Nicol" <[email-masked]>
Date: Wed, 25 Jul 2001 16:29:59 -0500

Section 2.4.2 of
http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-05.txt
contains:

   The method by which a server composes and validates an
   authorization identity from the authentication credentials supplied
   by a client is implementation-specific.

which is confusing. That "authorization identity" means UPN is a
difficult interpretation of that sentence to arrive at. I suggest:

   The method by which a server selects a UPN from the authentication
   credentials supplied by a client is implementation-specific.

to avoid misinterpretation.

2.4.2.1

   so the "ATTENDEE" property couldn't be munged to something misleading

s/couldn't/can't/

2.4.6
   The CUA may change the identity of a CAP session by calling the
   "IDENTIFY" command.  The Calendar Service only permits the operation
   if the session's authentication credentials are good for the
   requested identity.  The method of checking this permission is
   implementation dependent, but may be thought of as a mapping from
   authentication credentials to UPNs.  The "IDENTIFY" command allows a
   single set of authentication credentials to choose from multiple
   identities, and allows multiple sets of authentication credentials to
   assume the same identity.

I hope the defined syntax of IDENTIFY allow the CUA to present some
additional credentials at IDENTIFY time.  (also, the section listing
examples of small, large, dynamic and nested groups is in here twice.)

7.1.8
7.1.8 IDENTIFY Command

   Arguments: Identity to assume

   Data:      None

   Result:    2.0 .4 Identity not permitted

   The "IDENTIFY" command allows the CUA to select a new identity to be
   used for calendar access.  This command may only be called in the
   Identified State.

   The CS determines through an internal mechanism if the credentials
   supplied at authentication permit the assumption of the selected the
   identity.  If they do the session assumes the new identity, otherwise
   a security error is returned.

says that it does not.  Would it be possible to allow a second
AUTHENTICATE following IDENTIFY?  That would work for anonymous
delegation, which is the use case I've been trying to get CAP to
support with these endless harangues: the delegator could issue
a special UPN, for instance [email-masked]
and a password for it, which would be provided in an AUTHENTICATE
state after the IDENTIFY fails.

A way to do this that does not alter the state diagram might be to allow
IDENTIFY to include credentials as its data.

Thanks for your support

David Nicol

-- 
                                           David Nicol 816.235.1187
"Hush!" said the little boy's mother.  But it was too late.  The
emperor's agents had already heard his meek, innocent question and
were rushing through the crowd.  The emperor's agents took the boy
away and he was never, ever, seen or heard from again.

---

From: John Stracke <[email-masked]>
Date: Wed, 25 Jul 2001 22:09:21 -0400

David L. Nicol wrote:

> additional credentials at IDENTIFY time.

We discussed this before, I think, and the conclusion (IIRC) was that it 
was better to say that each connection AUTHENTICATEd just once; it makes 
the security analysis easier, which makes it easier to be sure that 
there aren't leaks someplace.

-- 
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |Reality is what refuses to go away when I stop|
[email-masked]|believing in it.                              |
\===============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Wed, 25 Jul 2001 22:04:35 -0500

> there aren't leaks someplace.

Right.  The connection authenticates once, and optionally sets up TLS,
so subsequent communication is secure.  Which means that from the
protocol's point of view, optional credentials to include with an IDENTIFY
command could be given in plain text, as data for that command.

Something like

  C:	IDENTIFY [email-masked]
  C:	petunia
  C:	.
  S:	2.0

For assuming identities that you already have access to because of who
you have already authenticated yourself as, the data would be optional:

  C:	IDENTIFY [email-masked]
  C:	.
  S:	2.0

Altering the existing authentication standards to store alternative
passwords
for alternative phantom users that you aren't logging in as at the moment
is a seriously vast request and I can't imagine anyone going for it.  All
existing authentication protocols seem to be about sharing
username/password
pairs without revealing them, with possible extensions geared towards
continuing
to validate the one authenticated identity.  IMO this is good modularity.

---

From: [email-masked] (Steve Mansour)
Date: Wed, 25 Jul 2001 21:09:20 -0700

> to avoid misinterpretation.

I think I follow you.  Paul, George, does this seem OK?

>    so the "ATTENDEE" property couldn't be munged to something misleading

done.

-Steve

---

From: George Babics <[email-masked]>
Date: Thu, 26 Jul 2001 10:38:14 -0400

> I think I follow you.  Paul, George, does this seem OK?

  Yes it does. It is much clearer.

---

From: John Stracke <[email-masked]>
Date: Thu, 26 Jul 2001 10:35:15 -0400

> command could be given in plain text, as data for that command.

It's not a question of secure from eavesdroppers; it's a question of 
secure from abuse.  If I AUTHENTICATEd with a particular set of 
credentials, then those credentials need to be checked for every 
operation I make.  In some cases, that's an expensive operation, so the 
server-side state will include some sort of cache, distilled down from 
the credentials.  (In the simplest case, this cache is the userid I 
authenticated with; but it could be more complex.) In some designs, 
there may be multiple caches (for example, in a layered architecture, to 
simplify the interaction between layers).  If I present another set of 
credentials, the server has to be absolutely certain that every single 
cache gets cleared; if anything gets missed, then we have a security 
hole.  Much simpler to permit only one set of credentials per 
connection; if you want to reauthenticate, reconnect.