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

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 27 Oct 2005 17:56:02 -0500

Gents,

I think I'm probably due to clarify a few things in this discussion.  There seems to be a lot of speculation about what I am saying.  Inline comments are intended to clarify...no promises though.

In general, I agree that authentication mechanisms aren't generally useful - an identity may be asserted by any number of means, the means of which should be transparent to a user.  I do wonder though, if it might be reasonable to provide some way for a user to specify the strength of authentication required.  Alternatively, it might be better to specify a minimum strength of authentication.  That is, take the onus off the user and absorb the complexity in specification.

Hannes Tschofenig writes:
> 
> hi aki,
> 
> please find my comments inline:
> 
> Aki Niemi wrote:
> > Hi,
> >
> > ext [email-masked] wrote:
> >
> >> 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.
> >
> >
> > 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.
> 
> 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
> "
> 

I understand the pressures placed on getting the document complete, but I don't subscribe to the theory that you need to understand all the use cases before you can adequately provision for extension.

For extensibility, I believe that all you need to do is understand the abstractions (identity, partial identity) used in the document and use containers that can hold the existing pieces (one, many) as well as other instances of that abstraction.

I'd suggest that maturing this document a little way would help with understanding extensibility in common-policy.  I've read the draft you mention briefly, but I'll take an action to give you some feedback.

> >
> >> - 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?
> 
> we are not going to address them by the common policy document, as
> agreed. as such, we are going to ship the document soon.
> 

I am (perhaps naively) optimistic that the draft will only need one more draft with any substantial changes.

> 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).
> 
> >
> >> - 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.
> 
> this is something jonathan has to address in the presence authz document.
> 
> >
> > 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.
> 
> 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.
>

Perhaps I should have used x500, rather than x509.  The identity information that I wanted to convey was the X.500 directory information, which is not a single value.  For instance: CN=first last, OU=org unit, O=org, L=city, ST=state, C=AU.  Note that this makes a distinction between the means of authentication (x509, perhaps) and the actual identity information.

> 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.
> 

Incidentally, I understand how you might use http to authenticate a user (digest for instance, although https might be safer).  But I can see how the example was constructed, but its construction inherently implies that the scheme includes an authentication method - it implies 'servercert'.  If the scheme is changed to 'host', then the means of authentication is not implied.

> >
> >> 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.
> >

Such a scheme might be feasible for any extension - I'd prefer XML encoding for identity information, but that could work.  That makes me think - it appears that the scheme attribute might be an identity scheme rather than direct URI scheme.  Therefore, it might make sense to place some kind of constraint on it (recommend IESG review for new values, IANA registry).

> >
> > 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.
> 
> 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.

All sounds good.  See above.

> 
> >
> >> 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... ;-)
> 
> great. your feedback is highly appreciated.
> 
> 
> ciao
> hannes
> >
> > Cheers,
> > Aki
> >

Ta,
Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 31 Oct 2005 09:22:31 +0100

hi martin 

> Gents,
> 
> I think I'm probably due to clarify a few things in this 
> discussion.  There seems to be a lot of speculation about 
> what I am saying.  Inline comments are intended to 
> clarify...no promises though.
> 
> In general, I agree that authentication mechanisms aren't 
> generally useful - an identity may be asserted by any number 
> of means, the means of which should be transparent to a user. 
>  I do wonder though, if it might be reasonable to provide 
> some way for a user to specify the strength of authentication 
> required.

that's very difficult to provide this. we went through this discussion
some time back and we even found a document that provided some help.
however, as it turns out it is difficult to say something about the
strengh of the cryptographic algorithm because it heavily depends on the
environment where it is used. 

>  Alternatively, it might be better to specify a 
> minimum strength of authentication.  That is, take the onus 
> off the user and absorb the complexity in specification.

we once discussed the possibility to reuse a proposal described with an
(expired) Internet Draft: Authentication Mechanisms Levels
(draft-zeilenga-auth-lv1-01.txt), Kurt Zeilenga, April 2001 which
proposes different authentication levels. here they are:

Authentication Levels
=====================

None (no authentication)
Examples:
- SASL Anonymous [RFC2245]
- Authentication based on source IP address
- Diffie-Hellman

Weak (vulnerable against eavesdroppers)
Examples:
- FTP USER/PASS
- POP3 USER/PASS

Limited (no protection against active attacks)
Examples:
- One-time Passwords
- HTTP Digest Authentication
- IMAP/POP Challenge/Response

Strong (protection against active attacks)
Examples 
- SRP Telnet Authentication
- Public Key Authentication 

the proposal is to specify only the categories (none, weak, limited and
strong) without enumerating all the different authentication protocols
itself. the actual authentication protocols are important and not the
protocols that are used to protect the messages itself. an example:
indicating tls alone is insufficient. tls supports unilateral pk-based
authentication, mutual pk-based auth., kerberos, srp and pre-shared
secret based authentication. for unilateral pk-based authentication
(server to client) the client authentication is frequently moved to the
application layer with again a number of mechanisms. 

this already gives you an impression how complicated the story is. you
can just give a list of properties, such as mutual authentication,
perfect forward secrecy, etc. this is, however, also pretty complicated.

i am looking forward to see your feedback with regard to the extension
for the common-policy document. 

ciao
hannes

> I understand the pressures placed on getting the document 
> complete, but I don't subscribe to the theory that you need 
> to understand all the use cases before you can adequately 
> provision for extension.
> 
> For extensibility, I believe that all you need to do is 
> understand the abstractions (identity, partial identity) used 
> in the document and use containers that can hold the existing 
> pieces (one, many) as well as other instances of that abstraction.
> 
> I'd suggest that maturing this document a little way would 
> help with understanding extensibility in common-policy.  I've 
> read the draft you mention briefly, but I'll take an action 
> to give you some feedback.
> 
> > >
> I am (perhaps naively) optimistic that the draft will only 
> need one more draft with any substantial changes.
> 
> Perhaps I should have used x500, rather than x509.  The 
> identity information that I wanted to convey was the X.500 
> directory information, which is not a single value.  For 
> instance: CN=first last, OU=org unit, O=org, L=city, 
> ST=state, C=AU.  Note that this makes a distinction between 
> the means of authentication (x509, perhaps) and the actual 
> identity information.
> 
> 
> Incidentally, I understand how you might use http to 
> authenticate a user (digest for instance, although https 
> might be safer).  But I can see how the example was 
> constructed, but its construction inherently implies that the 
> scheme includes an authentication method - it implies 
> 'servercert'.  If the scheme is changed to 'host', then the 
> means of authentication is not implied.
> 
> > >
> Such a scheme might be feasible for any extension - I'd 
> prefer XML encoding for identity information, but that could 
> work.  That makes me think - it appears that the scheme 
> attribute might be an identity scheme rather than direct URI 
> scheme.  Therefore, it might make sense to place some kind of 
> constraint on it (recommend IESG review for new values, IANA 
> registry).
> 
> > >