Re: Why is there no ServerMinPrincipalType constraint

Bob Scheifler wrote:
>> Is that really true? Assuming I'm in a network and the server is able to
>> authenticate as some Kerberos principal that means that he has been
>> granted one in the KDC and that seems a certain level of trust to me.
>>
>> Also in a PKI environment in which I have an X.500 principal in my trust
>> store it means that the entity at the other end is known by me.
>
> In restricted circumstations such as you describe, it's also quite
> likely that simply requiring ServerAuthentication.YES is sufficient,
> without need for a type constraint.  So, I still find server type
> constraints uninteresting.

How do you do that ... I was only wondering something but now I'm
fiercely wanting to have the ServerMinPrincipalType. I guess your "So, I
still find ... uninteresting" does that ;-)

So for the record "I disagree Bob". Within a corporate environment
Kerberos is likely the most comfortable solution for arranging security,
but it doesn't lend itself very well for securing services involving
third parties (as it requires a trusted third party, the KDC, accessible
by all parties involved), for that kind of interaction a PKI solution
based on TLS is likely better suited.

So I think a typical scenario for preparing lookup services by a
'client' in a corporate environment also using third party lookup
services would be to trust all lookup services that can identify itself
as a Kerberos principal or that can identify as a specific X.500
principal [1]. This would require something as ServerMinPrincipalType
but also support by the SSL and Kerberos endpoints for a
ConstraintAlternatives [2] that can take constraints of different types,
namely ServerMinPrincipalType and ServerMinPrincipal which is currently
not possible.

With the omission of ServerMinPrincipalType all clients are forced to
administer the exact set of Kerberos principals putting an extra burden
on the deployers and with less flexibility (you can only hope the set of
principals doesn't change over time).

I can understand the effort to implement ServerMinPrincipalType and to
allow ConstraintAlternatives with constraints of different types are not
worth the trouble at this stage, but to dismiss it as "uninteresting" is
quite "unbelievable" to me.

[1] you can't really trust all X.500 principals (as server) as it is
likely that your trust managers contain loads of X.500 principals that
are merely for the purpose of identifying clients.

[2] ConstraintAlternatives is limited by the Kerberos and SSL endpoints
in a way that all the elements must have the same actual class
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]