Re: clarity on SRP vs cTLS, sTLS

Neal,

Neal McBurnett wrote:
> 
> 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?

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.

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

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

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

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

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.

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

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

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

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

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 protected]
Ireland                             http://www.baltimore.com