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

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

Charlie,

Thanks for your response. Please find my comments below.

On Wed, 4 Jul 2001, Radia Perlman - Boston Center for Networking wrote:
(well, it was Charlie, but...)

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

Yes.

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

Which other? The charter of the SASL working group (still forming)
does explicitly state that [new] SASL mechanisms are out of scope
(while they of course can be reviewed by that group). I do realize
that there is no time to produce yet another draft before London, but
the important thing right now, I think, is to discuss this and reach
some kind of common understanding.

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

Yes, and I think having PDM as a SASL mechanism makes sense anyway
(SRP is on its way too), so I support this.

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

Yes, I did.

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

Right. However, another way to solve this is to use a  private key
which is _in_ the credential package itself (e.g. PKCS #15). I think
this could allow for a cleaner solution.

BR,
-- Magnus