On WSS-OTP interoperability [Was: RE: [wss] WSS Minutes 2006-04-04]

["Linn, John" <jlinn@rsasecurity.com>]

To elaborate a bit on what algorithm interoperability may mean in the
WSS-OTP environment, I'll observe that there are four entities involved in
what's likely a primary use case:

(1) An OTP device (hardware, software, or paper) associated with a user,
which provides authenticator data (including an OTP value, and possibly
associated parameters) to be transferred along with the user's request.

(2) The source WSS endpoint, which accepts the authenticator data provided
by (1) and constructs and sends a corresponding OtpToken object. 

(3) The destination WSS endpoint, which accepts the OtpToken object sent by
entity (2) and extracts data from it for processing by (4). 

(4) An authentication service that has access to stored OTP-related data
(e.g., OTP generation keys) corresponding to the user or device in (1), that
performs processing using that stored data along with the received
authenticator data in order to validate the request, and that indicates the
result of that validation to entity (3). 

In this scenario, neither (2) nor (3) implement any OTP generation or
validation algorithm themselves.  Effectively, they provide a form of tunnel
that carries OTP-based authenticator data from its source at (1) to its
verifier at (4).  To perform a complete and self-consistent interoperability
test, it would be necessary for (1) and (4) to use a common method, and for
(2) and (3) to be able to generate and accept an OtpToken suitable to
represent that method.  

While support for OtpTokens carrying a common method is necessary for a WSS
entity pair (2) and (3) to interoperate usefully, this is not a sufficient
condition; additionally, devices and services (1) and (4) must also be
available and suitably provisioned on a per-user or per-device basis in
order for the actual OTP algorithm(s) to be performed.  While one or more
specific methods can be selected for purposes of testing WSS components,
this need not imply constraints on the OTP methods that are to be
implemented and used in conjunction with general WSS-OTP deployments.
Particularly in the intended context of a method-neutral framework, it would
seem inappropriate for the WSS-OTP specification to impose algorithm support
requirements on entities (1) and (4), which do not themselves act as WSS
processors. 

--jl

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 
Sent: Wednesday, April 05, 2006 2:50 PM
To: Michael McIntosh; wss@lists.oasis-open.org
Subject: RE: [wss] WSS Minutes 2006-04-04


> Paul - several people pointed to the fact that the algorithms 
> are trademarked and encumbered at the last meeting Ron - why 
> not make that algorithm the baseline of interoperability? 
> would the submitters not agree to at least one?

The HOTP algorithm is already published by the IETF in accordance with
Section 6 of BCP 79 

http://www.openauthentication.org/pdfs/HMAC_OTP_DRAFT_4.pdf
http://www.ietf.org/rfc/rfc4226.txt

Just to clarify here, is the issue being raised here the IPR relating to the
specific technology described in the draft or a requirement for at least one
algorithm that can be implemented on RF terms?

The intent of the submission as described in the abstract was to specify a
RF algorithm.


I have no problem obtaining either statement, my understanding was that the
HOTP license issue had been settled on submission to the IETF. The objective
was from the start for OATH to be RF. 

I just want to know what the statement it is that you need here.

smime.p7s