Not logged in | Login
Below is the questionnaire published to the field (jcaps-interest mail alis) and the corresponding feedback received.
Nils Pedersen: 80%; everyone asks for it, but less than 20% has plans for or is using it in their solutions
Didier Burkhalter: Atleast 50%
Dean Hansen/Michael Czapski: About 7 in APAC
1.2 Amongst these customers, do they have any existing implementation or infrastructure for Security? If yes, can you please list any details?
Nils Pedersen: notes put into appropriate sections
Dean Hansen/Michael Czapski: SRE, SME. One customer uses WS-Security - unknown framework.
1.3 Any preferred cryptographic providers? Eg: SUN, BouncyCastle, OpenSSL
Jason B: OpenSSL
Nils Pedersen: None. Probably want to know if it is safe and supported well in tooling.
Leo Van Den Enden: Sun
1.4 Are your client's particular about NOT using any Open Source crypto implementations – Eg: BouncyCastle, Apache XML Security? If yes, please state the concerns – Secure Random generator, support & services or organizational policy etc..
Jason B: No
Nils Pedersen: No
Leo Van Den Enden: Open Source is OK as long as it is supported by Sun. Else customer needs to audit the open source which is time consuming.
1.5 What type of cryptographic service is preferred – hardware or software?
Nils Pedersen: TransportLayer - Hardware and App Layer - software. If tooling had well integrated support for utilizing Hardware from dev perspective, this would also be preferred for app/msg layer.
Jason B: Whatever meets performance vs price tradeoff needs.
Leo Van Den Enden: Hardware
1.6 Government regulations we should consider. For eg: For US – FIPS, export regulations based on country, key size etc..
US - NIST Some of the standards to be considered are:
–800-95: Guide to Secure Web Services
–800-103: An Ontology of Identity Credentials, Part 1: Background and Formulation
–800-54: Border Gateway Protocol Security (Internet Gateway routers best practices)
–800-94: Guide to Intrusion Detection and Prevention (IDP) Systems
–800-98: Guidance for Securing Radio Frequency Identification (RFID) Systems –800-80: Guide for Developing Performance Metrics for Information Security
1.7 Secure Random Generator? Default is Sun implementation of SHA1PRNG. Is there a requirement for a specific implementation – either provider or algorithm?
Leo Van Den Enden:SHA256PRNG
2.1 Which of the following protocol is the most widely used per your experience?
- SSL (Secure Socket Layer):
- TLS (Transport Security Layer):
- SASL (Simple Authentication and Security Layer - RFC 2222)
Jason B: SSL/TLS
Nils Pedersen: 60% SSL, 30% TLS and I haven't even seen SASL used in this context yet.
Didier Burkhalter: Atleast SSL
Dean Hansen/Michael Czapski: At minimum SSL v3 and TLS.
Leo Van Den Enden: SSL
2.2 For the above selected protocol, please specify the below details:
- Version? Eg: SSL v2, v3 etc..
Dean Hansen/Michael Czapski: SSL 3.0 & TLS 1.0
Leo Van Den Enden: SSL V3
- Maximum Encryption strength required eg: 40-bit or 128-bit or ?
Ans: 128 bits.
Nils Pedersen: Largely 128b. Unusually longer keys such as banks - upwards to 1024b in rare cases.
Dean Hansen/Michael Czapski: 128 or better
Jason B: Not many since it is hard to use in CAPS 5.x
Nils Pedersen: 2 Customers in Norway looking at using it.
Dean Hansen/Michael Czapski: It being a serious ommision many customers ignored
Leo Van Den Enden: Financial Industry
3.2 What are various types of message security, customers widely use? Eg: SMIME, PKCS#7, PGP, XML Security (non-WS-*), WS-Security, Kerberos?
Jason B: WS-Security
Nils Pedersen: PGP, XML Security, WS-Security
Dean Hansen/Michael Czapski: Serious ommision from the product. Minimal support required S/MIME, XMLDSIG + XMLEnc. PGP as potential addition.
Leo Van Den Enden:WS-Security, PKCS#7
3.3 If there is a specific priority for the above, please specify.
Jason B: WS-Security with SAML and with X.509 Certs and kerberos
Nils Pedersen: Largest request is for WS-Security, followed by XML Security. Rest are mentioned in conversations.
Dean Hansen/Michael Czapski: S/MIME, XMLDSig, XMLEnc - since WS-Security already exists.
Leo Van Den Enden: WS-Security
3.4 Amongst these, can you provide any details on what software they use today?
Nils Pedersen: JCAPS, Websphere and Oracle Fusion.
3.5 What do they like about the above software?
3.6 Any functionality that they would like to have in near term and long term?
Jason B: Customers using SME, prefer to have a point-n-click interface instead of having to import jar files etc. - a config based implementation.
Also required is WS-Security with more than the username-token profile (currently supported in CAPS 6 HTTP BC).
Nils Pedersen: In CAPS it is hard to find and do right stuff from dev point of view, poor tooling, too many manual steps in production.
Dean Hansen/Michael Czapski: Easy to configure and use for a lay person.
Leo Van Den Enden:
Cipher Algorithms: RSA-2048 bits begining of 2009
Hashing Algorithm: SHA-256 by begining of 2010
Digital Signature: RSAWithSHA256 by begining of 2010
Below questions are technical details that will help us prioritize in selecting appropriate crypto providers and also in testing.
3.7 What are the preferred Cipher algorithms?
- Block Algorithms Eg: AES, AESWrap, Blowfish, DES, DESede (3-DES, Triple-DES), RC2, RC5, RC6 or ??
- Stream Algorithms: ARCFOUR, RC4 or ??
- RSA, ECIES((Elliptic Curver Integrated Encryption scheme) or ???
- Cipher Algorithm Modes: CBC, CFB, CFBx, ECB or ??
Jason B: AES 128 bit (min strength)
Nils Pedersen: DES, RC*, 2: ?, 3: RSA (only heard hardcore sec people mention ECIES)
Dean Hansen/Michael Czapski: Most users with little knowledge on crypto details use RSA. Users who prefer non-patented algorithms choose AES or 3DES. CBC is typically chosen with 3DES because SSL algo combination combine them...
Leo Van Den Enden: Cipher Algorithms:
Asymmetric: RSA - 2048 bits Mandated by begining of 2009
Symmetric: AES with CBC - 256 bits
Hashing Algorithms: SHA256 - Mandated by begining of 2010, SHA1 (160 bits) until begining of 2010, MD5 (128 bits) existing usage.
MAC Algorithm: HMAC with SHA256 (usable key length=256 bits - Part of Digest used = 128 bits), SHA-1 (usable key length=128 bits- Part of digest used=80 bits).
Digital Signature: RSA (2048) with SHA256, RSA (2048) with SHA-1, RSA (1024) with SHA-1/SHA-256
3.8 What are the most widely requested signature Algorithms – RSA, DSA with SHA1, SHA256, SHA512 etc..? Please specify both sign algorithm and hashing functions.
Nils Pedersen: RSA and ECDSA with SHA2+ (SHA256, SHA384, SHA512)
Dean Hansen/Michael Czapski: SHA1. Especially in the absense of better knowledge. Leo Van Den Enden: SHA256
3.9 What signature format's are the most widely used?
Nils Pedersen: Enveloped Dean Hansen/Michael Czapski: Any Leo Van Den Enden: Enveloped
4.1 How do customers manage their Private Keys? Please provide any details on existing infrastructure or products used.
Eric Lerognon: Used http://portecle.sourceforge.net/ to manage keys and certs. The 505 product had too many stores - one for keystore, one for trusted certs and one for public keys. - Bottomline is that it is confusing. In 51x, keystores are in LDAP which has the benefits of being able to change the keys without restarting the server. eXchange web app was confusing. Can not use third party tools for LDAP based keystore.
Jason B: App server provided store
Nils Pedersen: Most have poor cert handling tools. Only trained people handle certs and are stored in machines not connected to network or in a secure-room.
Dean Hansen/Michael Czapski: GUI to manage KeyStores is very important. IBM's keytool is frequently used.
Leo Van Den Enden: Application Server
4.2 How do existing customers manage their Certificates and partner certificates? Please provide any details on existing infrastructure or products used.
Eric Lerognon: Used http://portecle.sourceforge.net/ to manage keys and certs.
Jason B: App server provided store
Nils Pedersen: In CAPS, insufficient support for administering cert and cert stores in large organizations.
Dean Hansen/Michael Czapski: CAPS 50 eDesigner UI, OpenSSL, Keytool, IBM Keyman. Windows customers also use windows utils and whatever comes with ActiveDirectory.
Leo Van Den Enden: Application Server
4.3 What are the most widely used KeyStore types? JKS, PKCS#12, PKCS#11, JCEKS or others?
Nils Pedersen: JKS, PKCS*.
Dean Hansen/Michael Czapski: JKS and PKCS#12
Leo Van Den Enden:JKS
4.4 KeyStore types that customers would prefer to have?
Dean Hansen/Michael Czapski: Customers do not have a specific preference - primarily what ever support is provided in the software and that works.
4.5 Most widely used storage for KeyStore / CertStore? Eg: File, LDAP, DB etc..
Jason B: File Nils Pedersen: LDAP. Existing CAPS customers use IS keystore. Dean Hansen/Michael Czapski: What ever the software enforces.
Leo Van Den Enden: File, LDAP
4.6 What would be the preferred storage customers would like to have for KeyStore / CertStore?
Nils Pedersen: Dont know
Dean Hansen/Michael Czapski: Any. Preferrably not DB for which extra bucks to buy, set up and look after.
4.7 What are the most widely used Certificate formats? Eg: X.509, PGP, SDSI
Nils Pedersen: X.509, PGP
Didier Burkhalter: X.509
Dean Hansen/Michael Czapski: X.509
Leo Van Den Enden: X.509
4.8 What are the different Certificate encoding's used by customers? Eg: ASN.1 DER, PEM (base64 encoded DER), .p7c (signed data structure without data, only Certs or CRL's), PKCS#12.
Nils Pedersen: Base64 encoded DER
Dean Hansen/Michael Czapski: PEM and DER minimum
Leo Van Den Enden: ASN.1
4.9 Do customers require export of Certificates. If yes, how high is the priority?
Dean Hansen/Michael Czapski: Most of the tools support this functionality. Hence the tool MUST support.
4.10 Has there been a demand for provision to generate Self-Signed Certificate (Public key, Private Key pair)?
Jason B: Yes
Nils Pedersen: Not for production purposes, but would be good to have for research and dev.
Dean Hansen/Michael Czapski: Most of the tools out there provide the functionality. Hence this should be considered by default.
Leo Van Den Enden: Yes
4.11 What are the existing types of Certificate validations used by customers? What would be their preference?
- Date validation
- CRL (Certificate Revocation List) validation
- Use OCSP (Online Certificate Status Protocol)
- How mandatory is the cache implementation for the above?
Nils Pedersen: Certain level of caching required. Cache refresh and lifetime should be configurable. Customers would also like to restrict the number of CA levels involved. For eg: customer would like to have max 3 levels of CA.
Dean Hansen/Michael Czapski: Most customers do not care about CRL or OCSP, especially given the added infrastructure required and understanding.
Michael - 'I, for one, would like to see better support for CRLs for these customers who desire to use them and I would like us to provide an easy-to-implement/deploy solution for implementation of OCSP support. Customers we are dealing with are not voume of crypto messages customers so the question of cache has never arisen since the question of OCSP has never arisen'.
Leo Van Den Enden: Date Validation
4.12 Are any of the customers using a Certificate life management tool / product i.e one that handles certificate expiry notification, renewal, switch over from one certificate to another etc..
Nils Pedersen: Unknown. Leo Van Den Enden: No
4.13 If yes to above (12),
- What features they like about the existing product?
- What features they would like to have in the product?
Nils Pedersen: support for administration of certs and cert stores in large organizations. Simplify tooling for registration of certs and trusted issuers list.
Also the ability to create keystores independent of app server domain. Infact restrict the keystore to the particular application itself and not exposed to other applications. Detailed comment below: (There is no way to package Cert./Key stores within the applications. So when your application needs certs it has to get it from the IS domain's key store or it has to be an external key store. Now sharing cert's in a IS domain means that if multiple application/projects would reuse/have access to all the certs installed to that domain. It would be better if there was a way that made it possible to either; package a cert/key store with the application or limit the access to the certs in the server (application level ...). Today when customers wants this (I've been asked twice about this) I've had them set up external stores (LDAP) and used LDAP ACL to limit the access to the certs.)
4.14 What are the most widely used private key encoding formats? Eg: PKCS#8, PKCS#12
Dean Hansen/Michael Czapski: PKCS#12 and Microsoft (whatever the format is..)
Leo Van Den Enden:PKCS#12
4.15 Do customers require export of Private Keys? How high is the demand? Which formats would they like to export to – PKCS#8, PKCS#12 etc..
Nils Pedersen: No
Dean Hansen/Michael Czapski: Exporting a PrivateKey from JKS KeyStore and importing to PKCS#12 is nearly impossible. In general it has been impossible to create a JKS keystore using an existing PrivateKey generated by a tool like OpenSSL. Any customer who uses both keystore formats require to export PrivateKeys, especially when they have to pay significant money for CA-Signed certs.
4.16 Do customers see a need to change the password of an existing KeyStore or Private Key?
Nils Pedersen: Yes
Dean Hansen/Michael Czapski: Yes. Password change is typically associated with transfer of authority.
Leo Van Den Enden: Yes
4.17 Is there a demand for Symmetric Key (or Secret Key) usage for encryption and signature of content? If yes, please state the number of customers and how you would prioritize it over PKI.
Nils Pedersen: Unknown
Dean Hansen/Michael Czapski: Since product does not support symmetric key, no demand really seen. But for internal use within organizational boundaries, symmetric cypto is much efficient than Public Key Crypto. Required for non-WS-Security mandated message security.
Leo Van Den Enden: AES + CBC(256bits)
4.18 What are the different Key Size's that customers request support for - 1024, 2048 etc..? Please state the max size expected?
Nils Pedersen: 1024. Expect to increase with faster PC.
Dean Hansen/Michael Czapski: 2048. As hardware perf improves over time, this will increase.
Leo Van Den Enden: 1024, 2048
Jason B: username/pword, certificate, SAML, some WS-Federation
Nils Pedersen: JAAS for Application level Authentication, SAML for federated.
Didier Burkhalter: user id/pwd, certificate based
Dean Hansen/Michael Czapski: No known JCAPS customers using SAML. Probably using it for other purposes. ID / pwd used for logging into some of the software eg: ED etc.. while certs are used when required by software/protocol (AS2).
Leo Van Den Enden: username/password, identify card (certificates), Radius
5.2 How many of these customers have an exclusive Authentication framework's already? For eg: Do they use Application server or depend on eWays or Binding components or any other. If yes, please answer the below.
- What do they like about the existing product?
Leo Van Den Enden: There should be "One" product where all security information is managed and stored.
- What they would like to have that is missing in existing product?
Leo Van Den Enden: WS-Security with Access Manager for composite applications.
5.3 Any feedback from customer on other Security products offerings?
Cust1: Is Authentication one or two factor authentication? Factors are known secrets (password, code, Zipcode etc.) along with a valuable in pocession (card, token, usb device) etc.. (from customer Queen's Medical)
5.4 Authorization: What % of customers use Authorization and how widely is it deployed? Eg: Every service invoked requires authorization or only a selective set of components.
Jason B: selected set of components based on auditing policy of company/country
Nils Pedersen: ~5%. Always required to bid.
Leo Van Den Enden: Preferably every service invocation requires authorization if the context of the user is known.
5.5 If selectively deployed, can you please specify certain criteria based on which Authorization is mandated?
Jason B: policy of company / country
Nils Pedersen: Whether service is used by external applications or not. Service is supporting a GUI scenario.
Leo Van Den Enden:Per one customer, every Service is checked whether the user has proper authorization to execute the service. This requires that the context of the user is propagated.
The following section discusses about propagation of Principal subject and necessary credentials when a consumer requests access to a particular service. Identified scenarios are listed below without a demarcation of organizational boundaries.
6.1 Are the above scenarios valid?
Nils Pedersen: Yes
Leo Van Den Enden: Scenario (a) encountered at one customer. Expect the same at another customer that require strict control and audit of services used. This goes together with centralized management and audit of access control of services.
6.2 Any other scenario's missing from the above?
6.3 Amongst the above, what is the most widely used scenario?
Nils Pedersen: (a)
6.4 If the above need to be prioritized, how would you prioritize them?
Nils Pedersen: a, b, d, e, c
6.5 Considering organizational boundaries, would the above change? Do we need to consider additional requirements?
Nils Pedersen: Could be that if X and Z are in different security domains that the prioritization would change.
7.1 Have you come across any requirements for federated Authentication and Authorization?
Jason B: Yes
Nils Pedersen: 3 customers
Leo Van Den Enden: Government organizations
10.1 Audit of all activities?
Steven Erickson: Yes
10.2 Password Management: length, time periods, format (mix of digits, char etc.), sequence i.e using same pwd, admin reset, encryption etc.
Comment: Can we expect external services such as Access Manager etc to provide this functionality
11.1 Is there any specific requirement from above that you would like to prioritize?
Nils Pedersen: I see security as part of the governance story, and therefor I would like to have some more to fill in the gaps we have there as a whole. At least a more credible story then we have today. How will we support this in the development tools. Runtime support is nice, but if it is too hard to mark these things in the development then people will have a hard time utilizing what is supported in the runtime. So therefor I would prioritize to do this as easy as posible in the development tools rather than support 100s of different products and features.
11.2 Apart from the above is there a different means by which organizations are meeting their security requirements?
Nils Pedersen: VPN and secure GW's (like Data Power and Layer 7)
11.3 1.Any feedback regarding usability – minimal effort required from user to use Security services, annoying factors user would not prefer to do?
Nils Pedersen: When securing a service it should be much easier then what it is today. I've tested it in R6 and it is not easy even if you know what you want. Maybe a more out-of-the-box wizard style guide, and maybe even a higher abstraction to the property editors.
11.4. Please add any other requirements that you have come across and not captured in this document.
Didier Burkhalter: Ability to modify BC security features easily late in inception or by different team OR provide a security pattern / layer in front of Open ESB (like layer 7 features).
Leo Van Den Enden: Management of passwords. Passwords can not be stored in clear text. Customers are not happy with the answer the files need to be protected at the OS level. There should be a mechanism to encrypt passwords and stored in an encrypted way and decrypted when requested (SSHA-1? as used in LDAP?)