Subject: clarity on SRP vs cTLS, sTLS

From: Neal McBurnett <[email-masked]>
Date: Mon, 10 Dec 2001 13:08:59 -0700

First a quick question on the current draft.  What is the ServerID
for?  How does it relate to its dns or certificate names?  I see it
defined in the XML DTD, but not in the text.  When is it checked?

Now, some TLS questions.

Is SASL-SRP a "MUST-implement" protocol for all operations that
it is defined for?  Is that also true for cTLS?  Or can
an implementation ignore cTLS entirely?

It seems to me that use of cTLS expands the opportunity for attack,
since knowledge of the TLS user certificate allows the password to be
changed.  At a minimum, this should be laid out in the Security
Considerations section.  But the real questions is why cTLS should be
used at all - I don't see it in the requirements or motivations for
SACRED.

Text like this near the beginning of section 2.2 and in Security
Considerations might be appropriate:

 "Instead of SASL-SRP, the client can use cTLS and authenticate via a
 client-side certificate.  Use of cTLS introduces a security risk
 because an attacker who gains access to the certificate can change
 the password, the credentials, etc."

Now, how about sTLS.

Bootstraping account setup in this bootstrap protocol via sTLS implies
extra complexity and reduced security due to reliance on trusted
roots, CAs, and associated PKI in the client.  One of the scenarios
for SACRED is to download trusted root CA's for protocols like TLS, so
we end up with a circular dependency.  Is there any way to avoid this?

E.g. would it be possible to allow pre-configuration of an account on
the server and out-of-band transmission of userid/password, and use
SRP rather than sTLS for the InfoRequest operation?  Perhaps it would
be feasable to define minimum security requirements for SRP parameters
like HashAlg, N and g and let them be negotiated during
initialization?

Cheers,

Neal McBurnett <[email-masked]>
http://bcn.boulder.co.us/~neal/
GPG/PGP signed and/or sealed mail encouraged.  Keyid: 2C9EBA60

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Dec 2001 23:55:52 +0000

Neal,

> defined in the XML DTD, but not in the text.  When is it checked?

Hmm...Would "I can't remember" be an answer? :-)

I guess it'd be useful to help if a client cached server information,
but it does look like it could just be dropped.

> an implementation ignore cTLS entirely?

Currently says that clients can choose whichever they like but
servers must handle both.

> changed.  

Huh? You need to use the private key for cTLS. Maybe I'm misreading
you?

> At a minimum, this should be laid out in the Security

I agree it could be omitted, but once we include sTLS (useful for
account setup), then allowing cTLS doesn't seem too big a deal.

> we end up with a circular dependency.  Is there any way to avoid this?

Its not quite circular. I'd imagine a lot of scenarios would be ok
using different equipment at account creation time. I don't see any
way to allow on-line account creation without something similar to
sTLS, but if there were then I'd be interested.
 
> SRP rather than sTLS for the InfoRequest operation?  

Nothing in the curent draft disallows an implementation doing that,
but how you do it is out of scope for sacred.

> Perhaps it would

Sounds liks a good idea - anyone got good values?

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