View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002248 | 10000-007: Profiles | public | 2012-11-01 18:29 | 2013-01-10 17:26 | |
Reporter | Assigned To | Paul Hunkar | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Summary | 0002248: UA Part 4: 7.35.3 UserNameIdentityToken - Password Encryption | ||||
Description | CMPWG Nov-1: There are 2 descriptions for the password: "If the token is encrypted the password shall be converted to a UTF8 ByteString and then serialized as shown in Table 169." ...and: "If the SecurityPolicy is None then the password only contains the UTF-8 encoded password." The first sentence contains a policy in Part 7, but a corresponding Policy is not defined for the second sentence. With this new policy UA products will be able to legally utilize sentence 2. | ||||
Tags | No tags attached. | ||||
Commit Version | |||||
Fix Due Date | |||||
related to | 0002315 | closed | Paul Hunkar | 10000-004: Services | UA Part 4: 7.35.3 UserNameIdentityToken - Password Encryption |
|
Note sure what needs to be done - there is one ConformanceUnit for Username Password Security Policy and it describes that the password is to be encrypted by the algorithm provided by UserNameIdenty Token if the message is not encrypted. This is the complete text in Part 4: This token shall be encrypted if required by the SecurityPolicy. To me this is inconsistent since it says to provide a securitypolicy for the usertoken if the securitypolicy is none then later it say if security policy is none to not encrypt it. I think this text needs to be fixed first to be very clear. In my opinion, username/password and unencrypted password - should not be allowed (note encryption can be over VPN or something else). So part 4 text should include something like: This token shall be encrypted if required by the SecurityPolicy. If the token is encrypted the password shall be converted to a UTF8 ByteString and then serialized as shown in Table 169. The conformance unit in any case does not need to be changed since it say to encrypt the password with the algorthim provided - the algorithm can be NONE- thus no encryption. |
|
I think that another (I think we have mentioned on a CMP call previously) is in the case of embedded devices where they simply don't have the capacity to do encryption. I understand your viewpoint, but I really think that we need the flexibility to allow the vendors to use clear-text passwords so that there's more choice. I think that there's a general understanding that clear-text passwords are allowed when there's no security so it might be difficult to reverse that now? I do agree that part 4 definitely needs some clarifications about clear-text passwords. |
|
DEtermined in UA meeting that Part 4 need clarification , but no work is required for this conformance unit |
|
agreed to in UA F2F. |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-11-01 18:29 |
|
New Issue | |
2012-11-20 18:13 | Paul Hunkar | Status | new => assigned |
2012-11-20 18:13 | Paul Hunkar | Assigned To | => Paul Hunkar |
2013-01-07 07:58 | Paul Hunkar | Note Added: 0004397 | |
2013-01-07 15:58 |
|
Note Added: 0004400 | |
2013-01-09 17:00 | Paul Hunkar | Issue cloned: 0002315 | |
2013-01-09 17:00 | Paul Hunkar | Relationship added | related to 0002315 |
2013-01-09 17:04 | Paul Hunkar | Status | assigned => resolved |
2013-01-09 17:04 | Paul Hunkar | Resolution | open => no change required |
2013-01-09 17:04 | Paul Hunkar | Note Added: 0004407 | |
2013-01-10 17:26 | Jim Luth | Status | resolved => closed |
2013-01-10 17:26 | Jim Luth | Note Added: 0004411 |