Re: [TLS] the use cases for GSS-based TLS and the plea for

[Martin Rex <Martin.Rex at sap.com>]

Leif Johansson wrote:
> Martin Rex wrote:
> >
> > What I meant (and forgot to add) was "certificate-based credential
> > (self-signed when no PKI is used) as a mandatory to implement
> > feature for interoperability".
> >
> > If support of cert-based credentials is a mere MAY, then I am sure
> > there will be servers/services where installing or using a PKI
> > credential is impossible/defective/unusable, and you cannot complain
> > to the vendor because not-supporting it is fully compliant with the spec.
> >
> > Everyone will be happy when Kerberos can be used cross-organization
> > one day.  But until that day, I want to make sure that the customer
> > has the working alternative to use PKI when there is a need for it.
> >
> >   
> Its important to remember that _both_ PKI and Kerberos
> have cross-realm issues. The main difference is that many
> PKI implementations allow the users to disregard the lack
> of cross-realm trust (eg a pre-configured trust-anchor).

I beg to differ.  Several PKI toothing problem can be
entirely avoided by applications when the ACLs account
for both, subject AND issuer of a certificate in order
to support authentication from different independent PKIs.

SSL/TLS Client certificates from seperate independet PKIs
is fairly commen, the Web Browsers implement it and
client components in distributed application backends
normally also support it today. 


A Kerberized server that authenticates users from realms with
not trust relationship is somewhere between difficult (MIT Kerberos)
to impossible (Microsoft Kerberos)

At least there appear to be workable approaches to deal with
seperate Kerberos client credentials for independent realms
(probably because it is so difficult to solve the issue on the
 server end).


> 
> This is my way of saying that I agree with Nico that any
> arguments based on the fact that Kerberos doesn't have
> widely deployed cross-realm are just as pointless as
> arguments against PKI because there is no common
> trust-root: building federations is a hard problem and
> not because we haven't gotten the bits right.

I belief that a common trust-root is a stupid and flawed approach.
Of course, the PKI guys desperately need it, because without it
all their policy and name constraints stuff remains the
useless bloat that it is.

The Kerberos cross-organization problem exists because
of the security problems and administrative problems
of a cross-realm trust.

A common trust-root and relying on policy&name constraints
to work puts PKI technology into a similarily miserable position
as Kerberos so it is really stupid to go down this road.

Why do I need a dozen different plastic cards in my wallet?
Can't those issuer not simply agree on a single one?

Well, those issuers want to keep full authority over this card
and not have to ask or negotiate with others what they may and
may not do with a card.

Think of revocation policies.  Right now, each issue can seperately
decide when to renew or revoke their card and for which reasons,
and lots of other policies.  If you only had one card, the rules
would have to be very different (and organization would have
to revoke privileges instead of revoking your credential).

PKI is no silver bullet.  And if you want to make best use of
the existing installed-base technology today, you should probably
forget about common trust-root for online authentication.


>
> I do believe it is a requirement of any solution in this space
> that it be able to gracefully handle the case when the gss
> handshake fails (for whatever reason) by falling back to
> <whatever>. I think the text used to describe this in the
> draft can be improved and I will try to help by offering
> constructive comments later on.

I'm less enthusiastic about the aggressiveness of the fallback.
I hate (hiden) fail-overs, because they're often the root of
mysterious and hard to diagnose problems.

*I* strongly prefer an initial negotation that provides a high
probabilty that a particular method will succeed, and then
exactly one attempt, an error message when it fails and
NO (automatic) fallback.


-Martin

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls