Re: Compound authentication "issue"

Hi Magnus,

A couple of comments inline.

--dg


Nystrom, Magnus wrote:

>Dale,
>
>You raise some good points, please find my comments below.
>
[ ... ]

>I note that we do not specify use of the BEEP "serverName"
>attribute, although the client should know it. If we specified it, and
>also included (by reference or otherwise) the text in RFC 2818 I think we
>would be in a more defendable position. (I am also wondering why RFC 3080
>does not include text similar to the one in Section 3.1 of RFC 2818, but I
>take it now that it is relating to BEEP's framework nature, and the
>proper place for such text is in documents implementing a protocol based
>on BEEP).
>
I'd favor by-reference to TLS, digest-MD5, and BEEP -- amplification & protocol-specific detail should ensure the new document is whole/understandable.

>Your message also begs the question as to how/when credential download
>actually happens. It could be user-initiated, of course, but a more
>natural approach (with perhaps a better user experience), would be to
>"trigger"  this based on some event, e.g.: The user is asked to sign a
>form with JavaScript signText(). This creates a call to PKCS#11, and if a
>"SACRED-aware" PKCS #11 module is present and active, it will then contact
>a pre-configured SACRED server to get the credential. Another alternative
>is to have credential download to happen automatically at login (to the
>SACRED-aware application or the patform as such or similar).
>
I can envision a SACRED client that checks it's credential store at 
start-up / periodically.

>Social engineering attacks will always be possible (i.e. simulate a connection to
>a SACRED server through a plug-in, perhasp), so users must always take
>care not to do a sacred authentication to unknown hosts.
>
>To conclude then, at this point I am inclined to suggest that we add
>wording similar to what is in Section 3.1 of RFC 2818, i.e. that the
>SACRED client MUST check that the server name as presented through TLS is
>acceptable and the intended (BEEP "serverName" SHOULD (MUST?) be used, and
>must map directly or otherwise to the name authenticated in the TLS
>handshake.
>
Not sure what, if anything, we should say in the protocol document, but I see a need for the SACRED client logic to have access to the certificate chain presented to it by the TLS server at connect time.  That would allow the client logic to be more conservative than the normal TLS processing if/when that's necessary.  Didn't see very much about certificates in the current protocol draft.

Also, the protocol document should note what happens for any legitimate corner-cases that
exist because of the combined protocol, such as:

    sTLS authentication succeeds but the server's final digest-MD5
    response fails to authenticate the credential server

That is -- we connected to the right TLS server, the server believes the client knows the
digest-MD5 password(?), but somehow the server failed to prove it also knows the pw.  With digest-MD5, can that happen and, if yes, is that just a mutual-auth error?

>-- Magnus
>  
>
[ ... ]