[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
[ ... ]