OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


I apologize if I missed it, but I didn't see an answer my question?  

Based on your description, you illustrate WSS as a "tunnel" for OTP
data.  So, given that the U/P token is a framework for any kind of
provisioned password or equivalent is there a technical reason why the
OTP data can't be encapsulated in the U/P token's password field?  That
is, packaged by (1) and unpackaged by (4)?

-----Original Message-----
From: Linn, John [mailto:jlinn@rsasecurity.com] 
Sent: Friday, April 07, 2006 12:54 PM
To: Chris Kaler; Hallam-Baker, Phillip; Michael McIntosh;
wss@lists.oasis-open.org
Subject: RE: [wss] On WSS-OTP interoperability [Was: RE: [wss] WSS
Minutes 2006-04-04]

Thanks for considering potential design alternatives.  To restate, if I
understand correctly, the suggestion is to define an object that would
be opaque for WSS processing purposes, and which would be carried
(possibly under some encoding?) within a wsse:PasswordString as used by
UsernameToken.  Rather than reinventing a new blob wheel if such an
approach were to be pursued, we now have an evolved working proposal in
hand for an XML object to carry needed parameters for OTP-based
authentication: the OtpToken, whose definition comprises most of the
technical content of the proposed OTP-WSS-Token profile document.  Based
on initial consideration (though perhaps missing some subtleties), I
believe that it may be possible to apply this result within
UsernameToken, either through some form of representation within the
password as suggested above or (in a more XML-friendly form) through the
xsd:Any hook in wsse:UsernameTokenType.  The password type URI could be
used to distinguish between a conventional password and an OTP-based
authentication using an OtpToken, and to dispatch appropriately. Further
distinction among OTP methods is possible within the OtpToken itself. 

Two classes of layering alternatives for an OtpToken may be feasible, in
an independent profile or as an object to be carried in conjunction with
UsernameToken, but most of the information to be represented would
remain the same.  In either case, I believe that there is value in
representing OTP-related authenticator data within a standard XML-based
framework structure that can accommodate multiple methods.  Is there a
preference within the TC for adaptation based on UsernameToken as a
starting point and, if so, would there be interest in standardizing the
associated authenticator data representation, its specific integration
method, and supporting data (e.g., fault codes for exception reporting)
within the TC?

--jl

-----Original Message-----
From: Chris Kaler [mailto:ckaler@microsoft.com] 
Sent: Thursday, April 06, 2006 2:10 PM
To: Linn, John; Hallam-Baker, Phillip; Michael McIntosh;
wss@lists.oasis-open.org
Subject: RE: [wss] On WSS-OTP interoperability [Was: RE: [wss] WSS
Minutes 2006-04-04]

Sorry, but I am really confused.  If (2) and (3) are really just tunnels
for (1) and (4), which I can understand, then that would lead me to
believe that the way to encode the data is for (1) to create a blob that
contains all necessary data for (4) and pass it as a "password
equivalent" with the corresponding username.  In this way every existing
(2) and (3) will support OTP because everyone supports U/P as it is
defined today.  Then (4) can unpack and process.  If you need to
differentiate the blobs because a (4) supports different algorithms for
the same provisioned used (which I'm not sure I see as a common
scenario), then the password URI type exists today and can be used as a
switch point.

Doesn't this meet what you describe below?

-----Original Message-----
From: Linn, John [mailto:jlinn@rsasecurity.com] 
Sent: Thursday, April 06, 2006 7:34 AM
To: Hallam-Baker, Phillip; Michael McIntosh; wss@lists.oasis-open.org
Subject: [wss] On WSS-OTP interoperability [Was: RE: [wss] WSS Minutes
2006-04-04]

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. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]