RE: Wording of Session Security Requirements

Stephen,

>
> Your problem is that the wording makes "use of tls/srp" mandatory, as
> opposed to "implementation of tls/srp and use of something equivalent"
> mandatory?
>

Yes.
The wording of section 2.2 makes "use of tls/srp" mandatory, whereas the
wording of section 2.3.1 makes "implementation of tls/srp and use of
something that meets the security requirements" mandatory.

> If so, then wouldn't the change you want be that those sentences read,
> e.g. "This operation REQUIRES use of mutual authentication", with the
> later section stating that implementation of SRP & TLS is mandatory
> but allowing for other equivalent mechanisms?
>
> Personally, I prefer it as is, but could live with the change above.
>

This wording is fine but doesn't section 2.3.1 already makes this clear?


> I would not agree with removal of those sentences - how then would
> I know the specific security requirements for the different operations?
>

You would know by the table in section 2.3.1.

Gareth

>
>
> Gareth Richards wrote:
> >
> > In section 2, normative lines requiring either SRP or TLS have
> been added
> > to most of the sub-sections.
> >
> > For example,
> >
> > 2.1.3   Remove Account
> >
> >    This operation REQUIRES one of SRP or TLS mutual authentication.
> >
> > It seems that these lines could be interpreted as not consistent with
> > section 2.3.1 defining the security requirements of the six
> operations in
> > section 2.   Following the table is a paragraph that states that these
> > requirements may be met by several mechanisms:
> >
> >    The security requirements can be met by several mechanisms. This
> >    document REQUIRES credential servers to support TLS and SASL-SRP.
> >    Clients MUST support SASL-SRP or TLS.
> >
> > The new lines added to section 2 appear to not only require
> that SRP or TLS
> > be supported but that they be used.  This seems to be counter
> the recent
> > SRP adjustments which allow for the use of SASL negotiation in BEEP and
> > thus allow other mechanisms to be supported while mandating
> support for SRP
> > to ensure interoperability with good security.
> >
> > I therefore suggest that the first lines be removed from
> sections 2.1.1,
> > 2.1.2, 2.1.3, 2.1.4, 2.2.1 and  2.2.2.
>
> --
> ____________________________________________________________
> 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
>