Greg:
I'm painfully aware of the issues that you raise. Discussions about security
tend to be value laden, so as we go through the conversation that will
follow, let's each assume that the other is reasonably competent.
Before trying to answer your specific questions, let me start by
acknowledging that a modular system has a great deal of appeal to me. I
envision DCMS being used in two modally different kinds of ways, and I can
imagine subversion being used in these ways as well. Undoubtedly there are
other options I have not thought of yet.
1. As a purely internal configuration management tool. In this usage, the
pluggable module idea is really wonderful, because you very much want to
integrate with the existing environment fully.
2. As a distributed tool that crosses corporate or administrative
boundaries. The problem here is that there simply *isn't* a single source of
administrative authority, so most of the pluggable techniques we have don't
work very well. The problem isn't in the plugging, but in the fact that the
authentication designs aren't global enough. I'm motivated here to point out
that however wonderful PAM may be, I haven't seen an RSA PAM module yet (for
RSA, pick your favorate public key system). I'm aware of the patent
problems, but is there a design for one somewhere?
Ignoring implementation details that I will address below, the main risk I
see in a pluggable mechanism is that people will deploy CM servers in the
assumption that they are acting under model (1) and later discover that they
need to move to model (2). At that point they suddenly need to rewrite a
whole bunch of repository content to use a globalizable authentication
policy. I'm debating making a distributable public-key technology the *only*
method supported by DCMS to avoid this problem.
I don't like the idea of mandating a policy here. If we can come up with a
way to solve the conversion problem I'ld actually like to avoid doing that,
and I'ld appreciate any thoughts that you may have.
Policy Issues:
I should make clear that there are some hard policy issues here. If I (the
project administrator for "EROS") say that a user acting under "fred.pubkey"
can modify EROS.freds-branch, and you (an administrator of a replicate) have
a replicate, should it follow that I have authorized anyone holding
fred.pubkey to perform an update to the EROS project on your machine? That
is, how should we understand the nature of the replication contract vis a
vis authentication?
I claim that in the case I just mentioned the answer should be "yes".
Suppose instead that we require that the person with fred.pubkey make the
mods on my machine instead. You will then replicate them anyway, so
rejecting them on your machine doesn't change what will happen at all, it
only adds temporary inconsistency into the overall picture.
The point: there are a number of policy issues like this that are subtle and
that need to be thought through, and I'm not satisfied that I have done
enough of this. However, none of these issues have to do with
authentication.
So, with that said, let me answer some of your questions:
> How does your mechanism work in an NTLM environment? In a Kerberos
> environment? How about my good old /etc/passwd -based Linux box?
First, I understand your question, and under model (1) above I agree that
these are important. However...
In a system designed for cross-platform, cross-corporate distribution, the
proper answer is: "it does not and cannot, because none of these solutions
are adequately cross platform". Further, *all* of these solutions assume
that there is a central place from which "identities" are handed out, and
that this source is locally controlled. A truly distributed system will not
work if this is required.
> Is your authentication system sound? Has anybody else implemented it
> and reviewed it from a security/crypo standpoint.
Actually, I was born yesterday. Also, I have a sub-standard IQ.
There are well-established, widely examined mechanisms for public-key
authentication, and I intend to make use of them. The entire DCMS code base
is open source, and one of the early participants is active in the SPKI
effort. While I'm sure that the first few releases will have flaws we will
need to correct, these will hopefully be errors of implementation rather
than errors of architecture. The point is: I have some confidence that we'll
get careful inspection accomplished.
What I have in mind for the moment is to use off-the-shelf public-key
technology. I have been assuming RSA as a mental placeholder, but it may be
that X.509 mechanisms prove to be more appropriate. The RSA techniques have
the advantage that there doesn't need to be a central certificate authority.
The X.509 techniques have the advantage that there is a greater amount of
traceability. The two probably are not mutually exclusive.
The first important attribute that these two systems have that I consider
important is that the "password" can be public without compromising the
security, and that it can therefore be replicated safely without
compromising the repository. This is important, because it allows us to
safely store the user "identity" along with the change. In all of the
NTLM/UNIX-password/Kerberos mechanisms that I know about, the best you can
really do is store a uid-like number (please let me know if I am mistaken
about this). The problem with this is that UID 5902 may be a different user
in your administrative domain than in mine, so this is not a useful number
in a global repository. You can convert by generating public keys and
rewriting the repository before going "public", but this is a serious
administrative pain in the ass, and of course it breaks the compatibility
with the local mechanism. At the moment, given that I can't figure a way to
get both worlds, I'm inclined to skip the local compatibility and go
straight to public key. I can imagine ways to let people make the whole
thing transparent by associating a public key with each NTLM user, but I'ld
have to think about whether that's a good idea from a usability and
proneness-to-error standpoint.
It helps that the repository is append-only. Certain kinds of malicious
behavior are harder to do if the repository is append-only.
The second important attribute that these two systems have is that the
certificates do not rely on a local administrator to generate them. Any
server presented with an authentication byte string, can verify the
authentication of any user from any other server. In a Kerberos system (as I
understand it) if I cannot get to your kerberos server, I cannot validate
any users generated within your domain. Conversely, if I *can* get to your
kerberos server it becomes vulnerable to attack. Here again, please correct
me if I am ill-informed. I haven't looked at the latest iteration of
Kerberos.
> Subversion can operate in all of these authentication environments without
a
> problem.
If implemented as you plan, it can interoperate with all of these
environments. Whether this constitutes operating "without a problem" is a
matter of which requirements you are trying to meet. I'm not suggesting (or
at least, I don't *mean* to be suggesting) that the subversion design is a
bad design. Quite the contrary, I think it's a good idea and I wish I could
figure out how to fit it into my own model.
If I am suggesting anything, I'm suggesting:
a) Make sure that the authentication module interface can support X.509,
RSA, and similar public key technologies.
b) Consider the issues associated with later distribution, and at least
document some of the conversion hair people will need to deal with so that
they can make the most appropriate choice of authentication policy as they
set up their repository.
> But then somebody else packages one up that uses NT's distributed auth
> systems....
NT doesn't *have* a distributable authentication system, which is why I'm
not planning to deal with the compatibility issue. What it has is globally
unique UIDs. You still need access to the local server to authenticate, and
that is exactly the problem that I am trying to avoid ever having.
> If site A mirrors site B, then it is possibly a moot question on whether
> site A would also need the auth information. Aren't the auth'd users only
> doing their work at site B?
Certainly not! That would conflict with local (or peer) repositories. In
DCMS, a particular branch is "owned" for update by a single server, but read
access to other branches in the same project can be made from any replicate.
Also, the ownership on a given branch can be transferred.
What's the point of replication if you can't work on different repositories?
> Possibly, if you attempt to create a union of different repositories, then
> you could have a name clash. I'd posit that is an unimportant problem at
> this standpoint, and I would maintain easily remedied (by a simple
transform
> across the userid strings; gstein becomes gstein.lyra.org).
We disagree about this, particularly where open source is concerned. gstein
is a person who is only temporarily associated with an organization. For
purposes of managing an open source project we are concerned with gstein the
individual, and only secondarily with gstein the member of lyra.org. This
name collision needs to be addressed in the same way that name collisions
among any other type of repository object needs to be addressed.
In fact, "gstein" may be authorized to contribute from work, but may do most
of their actual coding from home. My claim is that the CM system is in fact
an administrative domain in its own right, and that when performing a
checkin "gstein" must be authenticated to the CM system, not just the
operating system. In model (1) the two authentication domains can be
unified, but this is possible due to the happy accident that the project is
proprietary, as opposed to being possible because it reflects the
fundamental semantics of the CM problem.
I'ld encourage using cryptographically unique names, and then using local
"pet names". I'ld send you a URL with a description, but the link to
University of Pennsylvania appears to be temporarily down.
Jonathan
Received on Sat Oct 21 14:36:05 2006