Subject: protocol progress

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Sep 2001 18:52:52 +0100

Folks,

Well summer's over so we should progress the sacred 
protocol draft. I've identified the following issues
from the various emails and from the London minutes.
Comments on these are welcome [my initial thoughts
on each issue are in square brackets].

From the London minutes there seems to be a concensus
that the WG should include SRP in its work, as the
must-implement authentication scheme. The questions
arising are:

1. should we specify both PDM and SRP schemes? [yes]
2. if yes, in one or more documents? [one]

There was also an issue about whether we should define
our authentication schemes using SASL or 

3. Should we rely on use of SASL for authentication or should
we define the authentication elements as part of our messages?
[Don't use SASL.]

4. Additional PKCS#15 profiling is needed. [Won't be in this
version unless someone volunteers text.]

Following on there are some more details:

5. Do we want one or two BEEP profiles [depends on 2 & 3 above]
6. The name of the I-D will change [depends on 1 above]

I'm sure there are other issues that we'll come across as we
write the draft, but those will be the major changes and I'd
encourage folks to discuss them on the list.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 18 Sep 2001 17:32:44 -0400

Date: Tue, 18 Sep 2001 18:52:52 +0100
   From: Stephen Farrell <[email-masked]>
   [...]
   3. Should we rely on use of SASL for authentication or should
   we define the authentication elements as part of our messages?
   [Don't use SASL.]

Is there any reason for this?

I don't understand why you'd want to do the work of specifying the
authentication messages and not do it in a way that can be reused in
other protocols.

I strongly disagree with [Don't use SASL.], especially since this is
being implemented in BEEP which already has SASL.

Larry

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Sep 2001 09:14:29 +0100

Larry,

Reason I put it in for now was that I'm not sure I know how to 
get a key from the SASL "layer" used in the payload (which we
need to do).

If others do know, I'm listening...

Stephen.

---

From: Magnus Nystrom <[email-masked]>
Date: Thu, 20 Sep 2001 13:23:39 +0200 (W. Europe Daylight Time)

Stephen,

Thanks for your summary. A few comments below.

> 1. should we specify both PDM and SRP schemes? [yes]

I don't see a strong reason why. With a suitable framework, it is
enough to specify one MUST. Actual other schemes can be described
separately, e.g. as SASL mechanisms, should we choose to follow that
path.

> we define the authentication elements as part of our messages?

There are both pros and cons of this. As pointed out by Lawrence, and
this was also my original view, the main advantage of BEEP in this
context is its built-in support for SASL. Otherwise http could be
regarded as a better choice since it is more common and more likely to
be accepted by, e.g., firewalls. The disadvantage of relying on the
transport for security protection of the channel is that
implementation in other transports, e.g. XML Protocol, may need more
work, and for certain transports the security may not be possible to
achieve. Anyway, wrt your response to Lawrence, the SASL layer would
protect the connection. Any extra keys needed, e.g. to decrypt the
credential themselves, would seemingly have to be derived by the
application using either the SASL interface or some separate
mechanism.

> version unless someone volunteers text.]

My suggestion of a simple profile is as follows: All clients MUST
handle a PKCS15Token containing at least one private RSA key and one
certificate coupled to this key and a set of trusted certificates. The
private RSA key would be encrypted. All clients MUST support the
PasswordInfo choice of a RecipientInfo structure (see PKCS #15).
I am not sure about SHOULDs, but CMS would apply for most of them,
since the protection in PKCS #15 builds on CMS/PKCS #7 anyway.

[...]
[...]

I suggest not making use of the extra upload prime, "pub" in the
current I-D, due to the complexity it introduces and the fact that a
public key in the package itself can be used.

I also attach some comments on the first I-D given by Burt Kaliski of
RSA Laboratories. The first ones may become moot when moving to SRP.

> * The password is used many times in different ways: as an input
> to the key generation process for the prime p; as a further input to
> the key derivation process for the DH session key; as an encryption
> key for the credentials. This appears to offer better security
> against certain attacks than systems that don't use the password as
> much, but surely presents challenges in constructing any kind of a
> proof.
>
> * In the download protocol, the server can't tell whether the user
> knows the password. Consequently, there's no way to shut out attackers
> based on the number of incorrect attempts. The server can slow down
> the rate of attack by throttling, but it seems as if it would be
> much safer to stop access after some number of failures, and it's
> not possible to do so.
>
> * Architecturally, I'd prefer to have the download process result in
> a symmetric key that can be used to unlock separately-encrypted and
> stored credentials. This way, different services can be constructed to
> obtain the symmetric key, with a common service for storing the
> credentials, perhaps with access control based on an additional key.
> This would also allow better tracking on downloads.
>
> * I'm not really comfortable with the idea of giving the
> administrator the ability, after a single password-based download,
> to change other users' credentials. This seems quite prone to attack
> -- administrators should have a separate interface, more secure than
> a password.

Cheers,
-- Magnus

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Sep 2001 13:23:45 +0100

Magnus,

Main open issue seems to be SASL or not.

> separately, e.g. as SASL mechanisms, should we choose to follow that

So you're for just working on SRP for now. Ok, I can buy that, but
would suggest we try to also maintain an I-D for PDM (as a subsidiary
document) if we can - just to make sure we're really "pluggable"
for authentication schemes.

> application using either the SASL interface or some separate

I still don't see how this really works - how is the SRP-established
session key used for BEEP - does it protect all traffic like TLS,
or is the key popped up the stack (somehow) to be available to
the payload handling code?

> since the protection in PKCS #15 builds on CMS/PKCS #7 anyway.

Will include that then.

> public key in the package itself can be used.

Agree.

> RSA Laboratories. The first ones may become moot when moving to SRP.

Let's revist when we're done with the next draft, but I think they'll
probably all be addressed.

Stephen.

---

From: Magnus Nystrom <[email-masked]>
Date: Thu, 20 Sep 2001 14:57:50 +0200 (W. Europe Daylight Time)

Stephen,

> for authentication schemes.

That's fine. But, depending on the chosen authentication framework,
this may turn out to be very easy (e.g. if SASL is used, then any
suitable SASL mechanism would plug in). I'd also love to see separate
I-Ds for other transports, e.g. SOAP - to make sure there is a
transport independence.

> the payload handling code?

It could be similar to how other SASL mechanisms providing a security
layer works - all traffic would be protected. See e.g. the description
of how SASL works with LDAPv3. But as I said, I am not certain anymore
that one should rely on an underlying transport's security features.

[...]
> probably all be addressed.

Fine, important though to keep them in mind when drafting, I think.

Cheers,
-- Magnus

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 20 Sep 2001 13:40:50 -0400

Date: Thu, 20 Sep 2001 09:14:29 +0100
   From: Stephen Farrell <[email-masked]>
   Organization: Baltimore Technologies Ltd.
   CC: ietf-sacred <[email-masked]>

I just scanned the requirements document and I'm not sure I understand
why this is a requirement.

Many of the vulnerabilities listed in RFC 3157 aren't specific to a
credential server but exist in any network authentication.  Since
SACRED will almost certainly define a new SASL mechanism, the
mechanism can resist most of these attacks.

Since such a SASL mechanism (like SRP) will presumably negotiate a
secure, integrity protected session, most of these can be handled.

V1, V2, V3: resisted using suitable SASL mechanisms

   V4.      An attacker could overwrite a repository entry so that when
            a user subsequently uses what they think is a good
            credential, they expose information about their password
            (and hence the "real" credential).

I'm not sure I understand this vulnerability.  In order to overwrite
the repository, the attacker has either subverted the authentication
mechanism (resisted using suitable SASL mechanisms) or subverted the
local security of the credential server.  Is it the later that we're
worried about?

V5 also appears to be a vulnerability due to subverting the local
security (physical or otherwise) of the credential server.

V6, V7, V8, V9, V10: all resisted using suitable SASL mechanisms.

   V11.     User enters password instead of name.

This is an interesting vulnerability that exists in many protocols.

So the desire to have the session key negotiated by the SASL mechanism
would be to resist an attacker say, stealing the credential server's
hard drive?

Sorry, I just feel like I'm missing something here.

Larry

---

From: Dale Gustafson <[email-masked]>
Date: Mon, 24 Sep 2001 08:39:23 -0500

Hi Magnus and Stephen,

A couple of comments, inline.

Best Regards,

Dale Gustafson

> application using either the SASL interface or some separate

To summarize what several have said; there is a relationship between the
transport layer protocol used and the list of "strong password" or equivalent
protocols that may be used to provide mutual authentication and, typically,
negotiate a secret key for the outer encryption layer (which is used to protect
messages exchanged thereafter within the session).

I think this implies that each protocol document will need to call out a common
mandatory-to-implement (MTI) authentication/session privacy method (which needs
to be usable with an arbitrary transport layer).  I suspect each protocol
document will also need to describe a list of optional authentication methods or
the list of capabilities that must be provided by any auth-method running above
the selected transport layer (e.g. to properly support credential exchange with
a roaming user who carries only a password)

Probably true irrespective of whether SASL is used or not.

> since the protection in PKCS #15 builds on CMS/PKCS #7 anyway.

We've agreed the secured (encrypted) credential is an opaque data object -- the
credential format profile is independent of the transport layer protocol.  When
we have more than one protocol document, we will likely want to avoid
duplicating this info.

BTW, I didn't see how one would specify PKCS #12 or other credential formats
which will be helpful for browser-based secure applications, etc.  That needs to
be added.

I agree with Burt Kaliski's comments but did have a little trouble parsing the
next to last item below.