Re: I-D ACTION:draft-ietf-sacred-protocol-beep-pdm-00.txt

[Radia Perlman - Boston Center for Networking <Radia.Perlman@xxxxxxx>]

This is actually Charlie Kaufman (ckaufman@xxxxxxxx) responding. My system
is down and I didn't want to delay responding any longer.

Magnus Nystrom wrote:

>
>Some initial comments:
>
>-I thought one of the advantages of BEEP in this context was it's
>built-in support for SASL. However, this draft does not make use of
>this support, and I wonder why. IMHO, the PDM mechanism could be
>registered as a SASL mechanism and then used here.

There are multiple ways this could be layered. PDM should be specified
and registered as a SASL mechanism. The work hasn't been done yet, though
I now don't believe it would be terribly hard.

Then there is the question of whether SACRED should use PDM directly or through 
SASL. The advantage of using it directly is that SACRED does not need all of the 
security properties that PDM under SASL would need to provide, and it could 
therefore be simpler to implement and have better performance. The disadvantage 
is that there end up being multiple specs and multiple ways of doing things.

I originally envisioned PDM for SACRED as a credentials download protocol only, 
with upload taking place over a more heavyweight protocol like SASL. In this 
mode, the protocol could be two UDP messages and the server could be stateless 
(contributing additional simplicity and providing some protection against denial 
of service attacks). The protocol could be simpler, and leave out (for example) 
the additional RSA key you ask about in the next question.

Requiring that the protocol support credentials upload as well as download 
brought back much (but not all) of the complexity of a PDM SASL mechanism. It 
still does not need perfect forward secrecy, however, which gives it a 
performance advantage.

Running the protocol over beep and encoding everything in XML eliminated the 
simplicity of implementation that would allow a stateless server and a simple 
model implementation that could be compiled and run without assuming other 
tools.

So at this point, the idea of specifying PDM as a SASL mechanism and using it 
through SASL is growing on me. SACRED would still have to specify the format of 
the PDM public and private credentials to be uploaded. And this restructuring 
would delay the process since a draft could probably not be completed in time 
for the next IETF meeting and it would involve another working group.

The layering issue should not delay discussion of other aspects of the protocol, 
and should be straightforward to change later should we decide to do so. How are 
we going to reach that decision? I suppose it would be helpful if I did the PDM 
as a SASL mechanism I-D so the two options could be more easily compared.

>I would also like to know more about the reason for having a temporary
>key(pair). It seems as somewhat of an overkill, but I could certainly
>be missing something.

I assume you mean the RSA key pair included in the PDM credentials. This is 
temporary only in the sense that it need not be certified by any CA and can (and 
should) be regenerated whenever a user changes her password. But it is not 
temporary in the sense of ephemeral. It exists so that someone who has read the 
PDM "public" credentials stored on the server, but who does not know the user's 
password, can't use that information to trick the server into replacing the 
user's credentials with garbage. Details are in a paper Radia and I are 
presenting at USENIX Security in August.

--Charlie Kaufman
(ckaufman@xxxxxxxx)