Re: Compound authentication "issue"

[Dale Gustafson <degustafson@xxxxxxxxx>]

Hi Stephen,

I think your suggested text clarifies the potential risks adequately (as
written).

Beyond that, we should think more about tying the two security protocols (sTLS,
digest-MD5) together, assuming that makes sense from a technical perspective.  I
think Magnus' suggestion to link TLS "domain name" and digest-MD5 "realm name"
together should be looked at more closely. Perhaps others have a better solution.

The larger risk here is that the new combo-protocol offers little or no security
advantage over sTLS with user-id/password authentication which, if true, will
severely limit implementor enthusiasm.

Best Regards,

Dale Gustafson



Stephen Farrell wrote:

> I'm trying to figure out what text we need from this thread.
> My current guess is that I ought add the following to the
> security considerations:
>
> "Various operations in the SACRED protocol depend upon server authentication
> being provided by server authenticated TLS. SACRED clients SHOULD take care
> that the correct server is at the far end of the TLS "pipe" by performing the
> checks which are listed in section 3.1 of RFC2818 [RFC2818]. Clients SHOULD
> also include the optional BEEP serverName field in their "start" message
> and SHOULD then ensure that the BEEP serverName is consistent with the checks
> on the TLS server described in RFC2818. Failure to carry out these checks
> could allow a spoof server access a user's credential.
>
> If the SACRED account password were to be used in some other, less secure
> protocol using DIGEST-MD5, then it might appear to be the case that a
> man-in-the-middle (MITM) attack could be mounted. However, this is not
> the case since the DIGEST-MD5 client hash includes a client-selected
> "digest-uri-value" which in SACRED's case will be  "sacred/<serverName>". In
> a MITM attack, those values will be something else. A MITM attack as
> described is therefore thwarted because digest-uri-value wouldn't match
> what the SACRED server is expecting."
>
> I've also changed the example in appendix B so it includes the
> severName attribute and therefore (partly) reads:
>
> I: MSG 0 1 . 52 158
> I: Content-Type: application/beep+xml
> I:
> I: <start number='1' serverName="sacred.example.org">
> I:    <profile uri='http://iana.org/beep/TLS'>
> I:        <![CDATA[<ready />]]>]]&gt;<![CDATA[
> I:    </profile>
> I: </start>
> I: END
>
> And finally, I added RFC2818 as an informational reference (on the
> somewhat dubious basis that its an informational RFC and a standards
> track RFC oughtn't reference such a beastie as normative). This is
> something the IESG might hit us over the head with later on.
>
> Since I hope to submit the -05 version today, I'd love to get comments
> on this, and hopefully before 4pm GMT!
>
> Cheers,
> Stephen.
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:stephen.farrell@xxxxxxxxxxxx
> Ireland                             http://www.baltimore.com