clarity on SRP vs cTLS, sTLS

[Neal McBurnett <neal@xxxxxxxxxxxxxxxxx>]

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 <neal@xxxxxxxxxxxxxxxxx>
http://bcn.boulder.co.us/~neal/
GPG/PGP signed and/or sealed mail encouraged.  Keyid: 2C9EBA60