[Geopriv] RE: comments to <draft-ietf-xcon-cpcp-xcap-01.txt>

From: Tschofenig Hannes ^lt;hannes.tschofenig@siemens.com>
Date: Tue Jul 27 2004 - 09:02:04 EDT

hi hisham,

thanks for your quick response. please find my comments inline:
 

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: Monday, July 26, 2004 1:54 PM
> To: Tschofenig Hannes; aki.niemi@nokia.com;
> petri.koskelainen@nokia.com
> Cc: geopriv@ietf.org; xcon@ietf.org
> Subject: RE: comments to <draft-ietf-xcon-cpcp-xcap-01.txt>
>
> Hannes,
>
> Many thanks for taking the time in reviewing the draft.
> Responses inline...
>
> > -----Original Message-----
> > From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com]
> > Sent: 26.July.2004 11:27
> > To: Niemi Aki (Nokia-M/Espoo); Koskelainen Petri
> (Nokia-NRC/Tampere);
> > Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> > Cc: geopriv@ietf.org; xcon@ietf.org
> > Subject: comments to <draft-ietf-xcon-cpcp-xcap-01.txt>
> >
> >
> > hi aki,
> > hi hisham,
> > hi petri,
> >
> > i went through your document and i like it. it improves the
> utility of
> > the authorization policies defined in the geopriv wg.
> >
> > there are a few things which i like to point out.
> >
> > - the name of this draft is misleading. you are not defining a
> > protocol. you define authorization policies.
>
> Part of the document defines authorisation policy. Other
> parts define the rest of the conference policy. Combining it
> with a transport protocol like XCAP gives you a full solution
> that an be named the conference policy control protocol.

you are certainly right that it provides a full solution when combined with
xcap (and the sip conference specific issues).

however, is it a good idea to combine things which do not necessarily need
to be placed into one document?

>
> > furthermore, the filename is also misleading. these protocols have
> > nothing todo with xcap itself.
> > i know that this is a historical left-over from jonathan's draft
> > naming.
>
> Actually I removed the word xcap from the filename, but the
> WG chairs insisted that it goes back in.

i can understand this reasoning.

>
> >
> > - would it be useful to separate the policies from the xcap usage?
> > actually, i have the same impression about jonathan's
> > <draft-ietf-simple-presence-rules-00.txt> draft.
>
> It is separated. The current draft has less than a page on
> XCAP, just to satisfy the XCAP base document mandatory sections.

well, throughout the document you refer to xcap.
the relationship between the authorization policies and xcap is confusing to
many people.

>
> >
> > - i took a brief look at the xml schema and noticed that you do not
> > derive it from the common-policy schema in the same fashion as, for
> > example, the geopriv-policy draft. why this?
>
> There were a couple of reasons:
>
> - the <identity> definition did not allow us to add <any> element
> - the <validity> element was not needed in CPCP
>
> For the latter, we can probably add text saying that CPCP
> clients and servers should ignore, but the <any> element
> needs to be there. This will depend on the answer to the
> question I ask few comments below about the <identity>
> element not being there.

i think that the <time> element corresponds to the validity element.

>
> >
> > - i wasn't quite sure about the structure of the policies.
> in section
> > 4.2 you list a few xml elements which build the conference policy
> > document (such as <setting>, <info>, <time>,
> <authorization>,....). i
> > got the impression that this document describes more than
> just authz.
> > policies which have the typical characteristic of
> (condition, action
> > [and transformation]). maybe we should discuss some aspects in more
> > detail next week (in san
> > diego) - if you
> > want.
>
> Sure, we can set up a time.
>
> XCON is scheduled for Monday morning and I would like to have
> the discussion before then. Is Sunday afternoon good for you?
>
> >
> > i asked myself, for example, the following questions:
> > * why isn't the <time>, <conference-uri> or the
> > <max-participant-count> part of the conditions element?
> > * why isn't the <allow-sidebars> element part of the actions
> > element?
> >
> > the info element is interesting. i wonder whether such an element
> > would be relevant for other authz usage domains.
> >
> > - <security-control> element:
> >
> > we also discussed such an element in the geopriv area (we called it
> > <encrypt>).
> > you only talk about the signalling traffic and the differentiation
> > between tls and s-mime (as a means to say e2e vs. hop-by-hop
> > security).
> > you do not talk about the actual data traffic (something like
> > 'confidentiality of data traffic between the conferencing
> participants
> > must be enabled if element X is set to true.)
>
> Every media stream might have a different protocol for
> security. Allowing one to be defined as a common data traffic
> security protocol seemed limiting.
>
> I thought to leave this up to the media protocols and local
> policy of conference servers. But I'm open to ideas.

does it help to indicate some protection for the signaling traffic if the
subsequent data traffic is not addressed?

>
> >
> >
> > - section 4.3.4.1.1 talks about the identity element. the section
> > says:
> >
> > "
> > However, the rules for interpreting the identities in
> > <id> elements are left for each application to define separately.
> > This document, however, does not define the rules for
> interpreting
> > identities in <id> elements in conferencing applications since
> > those
> > interpretation rules are signalling protocol specific.
> > "
> >
> > you might want to take a look at 3.1.1 of
> > <draft-ietf-simple-presence-rules-00.txt>.
>
> I originally had text in there, but I received comments
> saying that in XCON, we don't limit our selves to any
> particular signalling protocol and therefore will not add any
> text to a specific protocol such as sip and leave others out.
> Therefore it was decided to leave all text out. Do you think
> that this is not the right thing to do?

i think you need to provide some text for this section. i know that it is
not an easy task but otherwise it might be difficult to accomplish
interoperability. you need to specify clearly which identity is used in the
'using protocol' and compared with the value in the <id></id> element.

>
> >
> > - section 4.3.4.1.1.2 talks about the <any> element to match any
> > identity.
> >
> > you don't need this element since you can simply omit the identity
> > field and achieve the same behavior.
>
> But the <any> element refers to any identity, not any
> condition. Does leaving the <identity> element out imply any identity?

if you omit the <id> element or the <identity> element then the rule says
that you match with any identity.
i think that this exactly matches with your requirement. hence, i think that
the <any> element is not needed.

>
> >
> > - section 4.3.4.1.1.2 talks about the <unauthenticated> element.
> >
> > why do you need to use this field? if
>
> Some conferences need to allow unauthenticated users into the
> conference, or block them. The difference between
> unauthenticated and anonymous is that in the former, the
> conference focus does not know who they are. In the latter,
> the conference focus has authenticated the user, but the user
> requested anonymity from the conference.

if the focus does not know the identity of the conference participant
(because they have not authenticated to it directly or indirectly) and you
allow such behavior for your conference then you should create a rule which
does not include the <id> or <identity> element in the condition.

for the conference it makes no difference why it has no access to the
identity (unauthenticated or anonymous). the authorization policy engine
cannot make a decision based on the identity.

if you would like to hide the identity from other conference participants
then i would create either an action or transformation element which says
'provide anonymity'.

>
> >
> > - section 4.3.4.1.1.4 talks about 'Matching AnonymousIdentities'
> >
> > i would not place this element into the conditions section.
> > this is rather
> > an element for the transformation section. in geopriv we have
> > something similar but for location information. here you
> would change
> > the display of the identity to others in a conference.
>
> You misunderstood this one. As stated above, this is needed
> to allow or block users from joining the conference depending
> on if they are anonymous or not.

i am not sure about the value of differentiating
- unauthenticated users
- anonymous users

if you don't care about the identity of the users then you might care about
the availability of a passcode. in this case you don't need to specify any
identity based conditions.

if you don't care about a passcode and the identity then you simply allow
everyone access to the conference.
(assuming that the information about the conference is available).

>
> We leave what you talk about to the signalling protocol. For
> example, in sip, a user can set the From-header field to
> anomymous@invalid or whatever.

i know.

>
> >
> > a confusion might be created with the <anonymous> element
> defined in
> > 3.1.2 of <draft-ietf-simple-presence-rules-00.txt> which has a
> > different meaning.
>
> Oh well :) I guess they are different documents.

still, an alignment might be useful. maybe jonathan can also provide more
information on the idea of the anonymous element in his document. i will
send him a note.

>
> > btw, i do not think that the behavior defined in 3.1.2 of
> > <draft-ietf-simple-presence-rules-00.txt> is particularly useful.
> >
> > - section 4.3.4.1.1.13 talks about the pin codes. i would
> suggest to
> > move this functionality into the common-policy document.
>
> I'll keep an eye out for a conclusion on this issue in geopriv.

thanks.

>
> >
> >
> > - section 4.3.4.1.1.14 talks about 'Matching Passwords'.
> >
> > i would remove this element since it assumes that sip can carry
> > username and password elements or you define your own
> authentication
> > algorithm here. if a sip-based authentication algorithm with
> > (username/password) is used then you can just match the
> authenticated
> > identity.
>
> We use password here much like the PIN above. For example, if
> a user knows the password, then he is allowed to join. His
> identity is irrelevant.

i took a look at the document again. the type of both elements is currently
'xs:anyURI' which is not correct. i would understand the differentiation if
you say that pin is a number and password is a text string. however, i would
combine the two.

btw, in which sip header do you carry the pin/password field?

>
> >
> > - section 4.3.4.2.17 talks about 'Authenticating a User'
> > (<authenticate>
> > element).
> >
> > we also discussed the inclusion of such an element in the
> geopriv area
> > and finally dropped it due to the lack usefulness. the same
> was true
> > for the presence authz document. it is really difficult to say
> > something about a security level and it has very little
> benefit for an
> > ordinary user. you can take a look at our discussions, if you want.
>
> We need this since we have a requirement that a conference
> creator can decide the type of authentication needed for a
> user. You are right thought that the average user does not
> know. I'll bring it up during my presentation.

in san diego i can tell you what options we discussed. in our sip-saml work
we also found similar things.

>
> >
> > - section 4.3.4.2.6 to section 4.3.4.2.16 talks about
> modifying some
> > specific issues.
> >
> > i am not sure about the applicability of a meta-policy in
> the policy
> > document. for example, section 4.3.4.2.9 talks about 'Modifying
> > Authorization rules' which is basically a meta - policy to
> modify the
> > authz policies defined in the document.
> > such a behavior should be specified in a separate document
> since it is
> > generic to all authz policies: 'is an entity A allowed to
> modify the
> > authorization policies of entity B?' for most cases it might be
> > sufficient to say that the owner is authorized to modify its own
> > document.
>
> We have discussed this before. The conference policy needs to
> define who is allowed to make changes to the document. It was
> also agreed that the way this is defined is semantically and
> within the same document. Do you believe it is completely
> wrong to do it this way?

we have also discussed meta-policies in geopriv and in relationship with
presence based authorization policies. you can use the same policies to
provide this capability. however, defining it in the same schema could be a
bit confusing.

>
> It is not viewed a entity A modifying entity B's document. It
> is viewed as entity A is modifying the conference policy,
> irrespective of who is the owner of the document in the directory.

but typically you have an entity who creates the conference policies.
typically this entity is allowed to change the policies again. however, in
some cases you might have multiple persons changing the policies.

i see this as a generic problem where a solution could be useful for many
application domains (geopriv, presence, etc.).

>
> >
> > - a few things need to be fixed due to the change in the
> common-policy
> > document.
>
> Can you be more specific here? I haven't kept track of what
> changes were made to common-policy (besides the <uri> to <id> change.
yes. we can go through the document and discuss the issues. nothing to worry
about.

ciao
hannes

>
> Thanks,
> Hisham
>
> > additionally i think it is necessary to investigate the combining
> > permissions algorithm a little bit more.
> >
> > ciao
> > hannes
> >
> >
> >
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 27 Jul 2004 15:02:04 +0200

This archive was generated by hypermail 2.1.8 : Tue Jul 27 2004 - 09:09:48 EDT