January 25, 2007

Extending OpenID Authentication Scheme for Communication Systems

A few weeks back I had suggested that OpenID could be used by the end parties in an IP Communications session to authenticate the originator of the session. At that time I only a sketchy description of the procedure. The following is an elaboration on the procedure. I am open to hear your feedback.

Introduction
Recently OpenID has caught on the attention of many as a simple and effective way to authenticate users visiting a website. It is "is an open, decentralized, free framework for user-centric digital identity." It is noteworthy that for the purposes of authentication it is only required that the visitor and the OpenID Provider (OP) have a prior business relationship and none are required between the site owner and the OP. The objective of this note is to explore ways in which the OpenID mechanism be reused for other applications like authenticating an email sender or the originator of a SIP session. Since the OP can be the visitor, such an authentication scheme will not eliminate SPAM and SPIT. But it will be easy to maintain an effective whitelist and if necessary institute a "postage" like regime for people not on the whitelist.
This proposal is a modified version of an earlier and related proposal, OpenIDHTTPAuth.

Procedure
Terminology
We will use the terminology used in OpenID specification. Accordingly, in our context, the User Agent (UA) is the party initiating the communication session, the Relaying Party (RP) is the the other party in the session.
The suggested procedure is a simplified and adapted version of OpenID 1.1's "dumb mode".

  • The UA will send to the OP a checkid_immediate message omitting the parameter, openid.assoc_handle. After performing the customary authentication procedure, OP will return a response message. If the assertion is positive the response message will contain among other things the parameter, openid.assoc_handle.

  • The UA will pass along the contents of the response message to RP using the native protocol.

  • If the RP is interested in authenticating the UA's OpenID, it can invoke OpenID authentication procedure. RP can fetch the identity URL given above and discover OP's URL. It then issues a standard OpenID 1.1 check_authentication request to the OP,

Example Applications
EMail
The sender of an email can attach the validation response it received from OP to the email as an attachment with a well known file name. The recipient then can use the content of the attachment to authenticate it with OP.
 SIP
The initiator of a session can include the validation response it received from OP to the SIP INVITE message as a MIME encoded parameter. The recipient then can use the content of the parameter to authenticate it with OP. If the initiator did not include this parameter, but the recipient prefers to authenticate the initiator, the SIP protocol could be extended so that the recipient can request the authentication information by sending an INFO message.

Notes
If the UA did not include the necessary credentials, the RP can use the native protocol and ask the UA to initiate the authentication procedure.
As observed by OpenIDHTTPAuth, "This method of authentication is completely stateless and applies only for one request. The client must repeat the signature generation for each subsequent request, both because the request URL is part of the signature and because the identity provider can then use a different secret for each request to avoid replay attacks."

Security Considerations
Replay Attacks
It is important that OPs use techniques like nonce to reduce replay attacks.

Posted by aswath at January 25, 2007 02:16 AM
Related Posts Widget for Blogs by LinkWithin
If you do not have an OpenID, then please use www.enthinnai.com/unauopenid/anyblog.

 

Comments



Copyright © 2003-2014 Moca Educational Products.