Subject: [Geopriv] AW: Authentication mechanisms visible or not? (was: Re: AW: [Geopr iv]common-policy update)

From: [email-masked]
Date: Thu, 27 Oct 2005 11:51:36 +0100

hi aki,

i think we agreed to keep the common policy doc as simple as possible. 

however, there are some further issues that need to be addressed (as part of future work):
- how extensible is the current document ? can we define new features (such as those raised in the past)?
these extensions do not need to be developed right now. we might need to consider the feedback for the currently developed spec. first.
- the user interface issue: sure, users are not going to make decisions about authentication mechanisms. but this might not be the only use case of the geopriv policies. in other use cases this could make a lot of sense. the saml guys, for example, believe that this work is useful. let us see what happens.
- martin's aspects about the identifiers is indeed interesting but might not be a topic for the common policy document. his problem is that the identifiers used in http and transport layer security do not match nicely with the identifiers used in the common policy document. one solution might be to define a mapping in his http location delivery document to a uri/iri. martin, alternatively, asked whether one feasible approach would be to enhance the common policy used schemes to denote an x.509 distinguished name.  

my conclusion: there is no disagreement and no problem just some topics that require more thinking. a draft review of the common policy document would not hurt as well.

ciao
hannes
-- Ursprüngl. Mitteil. --
Betreff:	Authentication mechanisms visible or not? (was: Re: AW: [Geopriv]common-policy update)
Von:	Aki Niemi <[email-masked]>
Datum:		26.10.2005 16:57

Picking just one topic inline.

ext Tschofenig, Hannes wrote:
>>The //one and //many elements don't allow for extensible 
>>content.  How do I specify a user who is authenticated by 
>>means of providing an X.509 certificate?   Would this suffice?
>>
>>    <one id="subjectAltName" scheme="x509"/>
>>
>>..."x509" isn't a registered scheme though.
>>
>>Is the intent that the //identity element is not used for 
>>these alternate authentication modes, or that common-policy 
>>specifically forbids these?  I'll admit that the case for 
>>putting something like SAML elsewhere is might be OK, but do 
>>you want to extend that to all types of identity information?
> 
> this is an interesting question that needs to be discussed. 
> in some sense this is a question for the using protocols that use the
> common policy framework since they need to map the identities to the
> respective scheme. 

This has been discussed already many times, and we have concluded that 
making authentication mechanisms visible in common policy for the 
authorization rulemaker serves no purpose.

These authorization rules will be edited by ordinary users who will not 
understand what x509 vs. Basic vs. Digest vs. Kerberos means. It is 
really up to the using protocol to define how to map various identities 
derived from various authentication mechanisms (i.e., a "username" param 
of Digest, a SubjAltName from a cert and so on), and the users simply 
match identities knowing they are properly authenticated.

I would also argue that if you match based on something other than an 
identity, e.g., some role or trait, then that does not even belong to 
the identity condition, but an extension (like <trait> condition or 
something) is needed.

Cheers,
Aki

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Aki Niemi <[email-masked]>
Date: Thu, 27 Oct 2005 13:47:47 +0300

Hi,

ext [email-masked] wrote:
> however, there are some further issues that need to be addressed (as
> part of future work): - how extensible is the current document ? can
> we define new features (such as those raised in the past)? these
> extensions do not need to be developed right now. we might need to
> consider the feedback for the currently developed spec. first.

Extensibility is certainly an important topic. Expecially interesting is 
how the rulemaker and the policy server find out about each others 
supported features; expecting something to work and not finding out 
before applying it won't seems like a bad thing to happen.

> - the user interface issue: sure, users are not going to make
> decisions about authentication mechanisms. but this might not be the
> only use case of the geopriv policies. in other use cases this could
> make a lot of sense. the saml guys, for example, believe that this
> work is useful. let us see what happens.

Are we going to make common-policy address all of those additional use 
cases, or are we going to ship this thing in the near future?

> - martin's aspects about the identifiers is indeed interesting but
> might not be a topic for the common policy document. his problem is
> that the identifiers used in http and transport layer security do not
> match nicely with the identifiers used in the common policy document.

In some ways, SIP Digest suffers from the same problems. The "username" 
used in Digest typically has no domain part, and worse, it may be 
entirely different from the service identity of the user.

For example, my username in the system may be "apniemi", with which I 
authenticate to the example.com system, but my service identity might be 
"[email-masked]". Still, this is not a problem common-policy can 
easily address.

As for identities used in certificates in transport security, there 
might be a problem. Although the id attribute is a string, so if you 
wanted to authorize an http server, shouldn't this do the trick?

<identity>
   <one id="location.server.example.com" scheme="http" />
</identity>

Note that this would still say nothing about whether this identity 
is/was authenticated using an X.509v3 certificate, and I don't see why 
it should.

> one solution might be to define a mapping in his http location
> delivery document to a uri/iri. martin, alternatively, asked whether
> one feasible approach would be to enhance the common policy used
> schemes to denote an x.509 distinguished name.

Yes, I realized this is what he was asking. But the example he gave 
would match all requests whose identity was "subjectAltName" and came 
using the x509 protocol... So I don't think that approach works well; 
that information would need another way of representing anyway. IFF we 
were to go back on the earlier decision that authentication mechanisms 
are not visible in common-policy, that is.

> my conclusion: there is no disagreement and no problem just some
> topics that require more thinking. a draft review of the common
> policy document would not hurt as well.

I can agree to that, and take a personal action point to go through the 
whole document with a fine-tooth comb, and not only the identity 
section... ;-)

Cheers,
Aki

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Oct 2005 15:20:50 +0200

hi aki,

please find my comments inline:

> before applying it won't seems like a bad thing to happen.

we have written drafts in order to learn the capabilities.
please take a look at the three drafts related to this topic entitled as:

"
    An Extensible Markup Language (XML) Representation for Expressing
                       Presence Policy Capabilities
"

> cases, or are we going to ship this thing in the near future?

we are not going to address them by the common policy document, as 
agreed. as such, we are going to ship the document soon.

we don't even yet know whether we need these features nearby. still, it 
is valid to discuss these use cases and work that is being done outside 
the ietf (even though it does not impact the current document).

> "[email-masked]". Still, this is not a problem common-policy can 

this is something jonathan has to address in the presence authz document.

> is/was authenticated using an X.509v3 certificate, and I don't see why 

the aspect is not that simple. a few problems with your approach:
the identity that is used in martin's document (i don't know whether you 
have read it) refers to the identity used by the client side during tls 
authentication.

additionally, there is no registered scheme called 'http'. you cannot 
use something like this in the policies. this was one of martin's 
questions how you would extend the schemes.

> are not visible in common-policy, that is.

it is a good question whether martin referred to this or just to the 
problem of mapping an identifier to the respective scheme.

anyway, the concept of specific authentication mechanisms is outside the 
scope of the common policy document. the same applies to the x.509 
distinguished names.

> whole document with a fine-tooth comb, and not only the identity 

great. your feedback is highly appreciated.

ciao
hannes