0 Replies Latest reply on Jul 23, 2012 10:21 AM by anil.saldhana

    Challenge/Response enabled Authentication Framework

    anil.saldhana
    anil.saldhana Jul 23, 2012 10:21 AM

      Wondering if SASL is the perfect candidate for a challenge/response enabled authentication framework with multiple authentication mechanism support.

       

      Wikipedia entry on SASL.

       

      Apart from a challenge/response framework, it has support for the following protocols.

      A SASL mechanism implements a series of challenges and responses. Defined SASL mechanisms[1] include:

      • "EXTERNAL", where authentication is implicit in the context (e.g., for protocols already using IPsec or TLS)
      • "ANONYMOUS", for unauthenticated guest access
      • "PLAIN", a simple cleartext password mechanism. PLAIN obsoleted the LOGIN mechanism.
      • "OTP", a one-time password mechanism. OTP obsoleted the SKEY Mechanism.
      • "SKEY", an S/KEY mechanism.
      • "CRAM-MD5", a simple challenge-response scheme based on HMAC-MD5.
      • "DIGEST-MD5", HTTP Digest compatible challenge-response scheme based upon MD5. DIGEST-MD5 offers a data security layer.
      • "SCRAM", modern challenge-response scheme based mechanism with channel binding support
      • "NTLM", an NT LAN Manager authentication mechanism
      • "GSSAPI", for Kerberos V5 authentication via the GSSAPI. GSSAPI offers a data-security layer.
      • GateKeeper (& GateKeeperPassport), a challenge-response mechanism developed by Microsoft for MSN Chat

      The GS2 family of mechanisms supports arbitrary GSS-API mechanisms in SASL.[2] It is now standardized as RFC 5801.

       

       

      I consulted Darran about this and here are his thoughts.

       

       

      (09:09:34 AM) anilsaldhana: darran: regarding a challenge/response based authentication framework, do u think sasl is sufficient?
(09:10:34 AM) anilsaldhana: darran: given that it has many possible protocols including silent
(09:11:50 AM) darran: asaldhan, from a non-HTTP perspective my feeling is yes, some of the Java provided APIs are not as easy / safe as they should be but the actual process at the transport level is good, we could optimise to do more concurrently but thats about it really 
darran dehort 
(09:13:07 AM) anilsaldhana: darran: right. I was asking mainly from non-http perspective.
(09:13:19 AM) anilsaldhana: darran: thanks for the guidance.
(09:13:53 AM) darran: a couple of API examples are CallbackHandler issues related to not clearly advertising what is supported or what is needed regarding callbacks, from a mechanism perspective there is also a lack of 'lifecycle' say to confirm success or failure of an auth process but all of these could be addressed without afecting the underlynig use of SASL
(09:14:42 AM) anilsaldhana: darran: of course.

      PicketBox Core can natively support SASL. We will include darran's jboss-sasl project.