[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compound authentication "issue"
I agree with all that you wrote, except for the "we" bit. I'm not
at all sure that it'd be in our charter to develop any new mutual
authentication schemes, which is what I believe would be needed to
properly bind sTLS and DIGEST-MD5.
However, there will I believe be a new SASL WG which might want to
take on such things. I'm not sure.
Dale Gustafson wrote:
> Hi Stephen,
> I think your suggested text clarifies the potential risks adequately (as
> 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 />]]>]]><![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
Baltimore Technologies, tel: (direct line) +353 1 881 6716
39 Parkgate Street, fax: +353 1 881 7000
Dublin 8. mailto:stephen.farrell@xxxxxxxxxxxx