[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compound authentication "issue"


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