[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 don't see how this is different from having two X.509 certificates (or two SAML tokens) with which I must sign except of course that the password type URI provides additional semantics beyond what X.509 might convey. -----Original Message----- From: Symon Chang [mailto:schang@bluetitan.com] Sent: Friday, April 07, 2006 2:43 PM To: Linn, John; 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] John, I have questions for you: Said we have a use case of sending two credentials for two-factor authentication: one is user name and password, and another is OTP. Now, we have two design alternatives to be selected from: 1. Have two Username tokens in the security header: one for Username Token and another for OTP, depending on the wsse:UsernameTokenType. 2. Have one Username token and one Otp Token in the security header. The questions are: - Which approach will be less confusion for everyone? - Which approach will be easier to process at the receiving end? - Which approach will have better interoperability? Symon Chang, CISSP Sr. Security Architect Blue Titan Software -----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. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]