RE: Things to do - Requirement Document. Security.

[Michael Zolotarev <michael.zolotarev@baltimore.com>]

Hi,
The attached is [a very rough cut of] the security requirements for generic
Vote and Ballot tokens.
It doesn't mention the identification and audit - I don't consider them to
really belong there, in the security section.
Any comments are welcome. << I know that English is not perfect. Feel free
to fix it>>

Regards
Michael

> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: Friday, 15 June 2001 17:35
> To: Michael Zolotarev; election-services@lists.oasis-open.org
> Subject: RE: Things to do - Requirement Document. Security.
> 
> 
> Michael,
> 
> 	Good thoughts. Couple of observations:
> 
> |suggest we change the pitch of the message from "SHOULD 
> allow" and "SHALL
> |facilitate" to more permissive and broader "SHOULD NOT 
> prevent" and "SHALL
> |NOT make impossible".
> |
> 
> 	Sounds fine. But there would be many requirements which 
> we might have to
> express in active voice.
> 
> |know - the major participants and items, and associated security
> |expectations.
> 
> 	Keep in mind that we are talking about the requirements 
> of a voting system,
> not just security. So if there are non-security requirements, 
> let us capture
> them and move them to another section in the requirements document.
> 
> |	identification and traceability: << not quite a 
> security issue, though>>
> |	audit, identification and traceability: << not quite a 
> security issue,
> though>>
> 
> 	We need these. Again, we are looking at all 
> requirements, not just
> security. Identification, audit et al are security functions anyway.
> 
> |Structuring security requirements this way will allow 
> keeping it short and
> |sweet, and hopefully better associated with the overall picture.
> 
> 	Short, may be not. Sweet, depends :-) But I have no 
> problem if you want to
> restructure the points. Actually I was writing them as a 
> straight list to
> stimulate thoughts and didn't mean any organization.
> 
> |I believe that vote-casting environment should not be 
> included into the
> |security discussion. It has nothing to do with tokens/protocols.
> 
> 	Again, we need to touch upon the vote casting 
> environment in general terms
> in the requirements section. The more generic the better, but 
> still need to
> include any assumptions, requirements, ...
> 
> cheers
> 
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 



-----------------------------------------------------------------------------------------------------------------
"How can I make sure the right people get access to the right resources 
and business applications, with a user base that's constantly growing and
changing?" 
The answer... 
Baltimore SelectAccess 
Next Generation Authorisation Management 
http://www.baltimore.com/selectaccess/index.html
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
VOTE TOKEN.

R1. Voter identity. 
Structure and encoding of a vote token SHALL NOT preclude referencing the person who cast the vote (the Voter).

R2. Voter anonymity. 
Should a voter reference information be present in the vote token, the structure and encoding of the token SHOULD 
allow protecting the voter's anonymity, i.e. not to disclose the real identity of the voter.
<< referencing a voter by alias, ID, hash of a key, etc).

R3. Externally authenticated voter.
The structure of the token SHOULD NOT prevent referencing the voter by means of including/referencing an authentication 
token generated by a third party authentication services. For instance, a voter may be referenced by 
including/dereferencing a SAML assertion.

Vote Integrity, voter Authentication and Non-repudiation

R4. Structure and encoding of a vote token SHALL NOT constitute a technical barrier for implementing integrity, origin authentication and non-repudiation services. 
Specifically, a token's structure and encoding scheme SHOULD allow the application of the standard XMlDSIG signing to it.

R5. At the same time, the structure and encoding of a vote SHALL NOT mandate, and therefore make any specific provisions for, a particular
integrity, authentication and non-repudiation mechanism, such as XMLDSIG signing.

<< It'd be a bad idea to assume and to mandate XMLDSIG signing as the only possible mechanism to achieve N-R, integrity and authentication, 
and consequently to define the token in some kind of an XMLDSIG-dependant way. The requirements can be as well met by 
usign a password-based MAC, for instance. >>

R6. The application of a voter authentication mechanism and non-repudiation mechanism to a vote token SHALL NOT compromise the voter-anonymity requirement (R2).

Vote confidentiality

R7. Structure and encoding of a vote token SHALL NOT impose a barrier for implementing confidentiality services. 
Specifically, a token's structure and encoding scheme SHOULD allow the application of a standard encryption procedure.

R8. Structure and encoding of a vote SHALL NOT mandate, and therefore make any provisions for, a particular encrypting mechanism.

Note. It SHALL be possible to encrypt only certain components of the complete vote structure, rather than encrypting the whole lot.

BALLOt TOKEN.

R9. Voter identity. 
Structure and encoding of a ballot token SHALL NOT preclude referencing the identity of an intended voter.

R10. Voter anonymity. 
The structure and encoding of a ballot token SHOULD allow protecting the voter's anonymity, i.e. not to disclose the identity of the voter.

Ballot Integrity, origin authentication and Non-repudiation

R11. Structure and encoding of a ballot token SHALL NOT constitute a technical barrier for implementing integrity, origin authentication and non-repudiation services. 
Specifically, a token's structure and encoding scheme SHOULD allow the application of a standard XMlDSIG signing procedure to it.

R12. At the same time, structure and encoding of a ballot token SHALL NOT mandate, and therefore make any specific provisions 
for, a particular integrity, authentication and non-repudiation mechanism, such as XMLDSIG signing.

Ballot confidentiality

R13. Structure and encoding of a ballot token SHALL NOT constitute a technical barrier for implementing a
standard encryption procedure. Specifically, a token's structure and encoding scheme SHOULD allow the application of a standard XML encryption.

R14. At the same time, structure and encoding of a ballot token SHALL NOT mandate, and therefore make any specific provisions for, a particular encryption mechanism.

R15. Application of an encryption mechanism to a ballot token SHALL NOT negatively affect the voter-anonymity requirement (R10).

Note. It SHALL be possible to encrypt only certain components of the complete ballot structure, rather than encrypting the whole lot.