Hi Detlef, Yes! :) Kind Regards, Frank. > Op 30 jan. 2018, om 10:21 heeft Dr. Detlef Hühnlein <
detlef.huehnlein@ecsec.de> het volgende geschreven: > > Hi Frank, > > how about “security relies both on the security of the TLS-channel and the signature of the Assertion/ Response, > if these data flow through the User Agent”? … The latter is for example not true in the Artifact Binding. > > BR, > dh > > > > Von:
dss-x@lists.oasis-open.org [ mailto:
dss-x@lists.oasis-open.org ] Im Auftrag von Frank Cornelis > Gesendet: Dienstag, 30. Januar 2018 09:45 > An: dss-x <
dss-x@lists.oasis-open.org> > Betreff: Re: [dss-x] self-describing DSS-X instances > > Hi Detlef, > > > I quickly went through the article. Funny to notice that the User itself is not considered an attacker. The messages pass in clear text over his User Agent and can be very easily modified. In the context of SAML Browser POST with bearer tokens, an attacker will almost never focus on the transport layer, as he can target the protocol at the User Agent level much easier (see your Figure 5). I have performed several of such attacks in the past. Signature wrapping, … you name it. Check my commits at: >
https://github.com/OWASP/OWASP-WebScarab/commits/master > Believe me, this is really low hanging fruit. And besides, an entity authentication with proper TLS-binding is still very hard to implement in practice. > > Protocols like SAML Browser POST really require message-level security, maybe enhanced with some TLS-binding if technically possible. > > with respect to SAML (in the Web Browser SSO Profile with SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer”) > one should keep in mind, that the security effectively relies on the security of the TLS-channel and not the signature of the Assertion or > Response > > Maybe I still need some more coffee, but I really cannot believe that you wrote the above!!! > Am I missing something else here but coffee? > > > Kind Regards, > Frank. > > > Op 30 jan. 2018, om 08:58 heeft Dr. Detlef Hühnlein <
detlef.huehnlein@ecsec.de> het volgende geschreven: > > Good Morning Frank, > >>> Depending on the specific security requirements, a suitable >>> TLS-channel without any message level security might be sufficient. >>> Most real world systems which use SAML or OpenID Connect only use bearer tokens, which could be intercepted and misused by a sufficiently >powerful attacker. >> >> SAML is actually a good example. SAML Browser POST binding messages pass via the web browser, where you could perform a MITM despite SSL >between browser and both RP/IdP. That's why SAML Browser POST response messages are being secured via an XML signature. > > with respect to SAML (in the Web Browser SSO Profile with SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer”) > one should keep in mind, that the security effectively relies on the security of the TLS-channel and not the signature of the Assertion or > Response, because a MitM-attacker can sit in the channel between the User and the SP and just hijack the session > by handing over the Response to the SP. See Section 3.1 and Figure 5 in
http://www.ecsec.de/pub/SAMLizing-ECC.pdf . > > BR, > Detlef > > > <image001.png> > > > > Kind Regards, > > Frank. > > > On 01/29/2018 04:54 PM, Dr. Detlef Hühnlein wrote: >> Hi Frank, >> >> I think that your statement below “A non-SOAP binding requires message-level security, obviously by means of XML signatures.” >> is not true in general. >> >> Depending on the specific security requirements, a suitable >> TLS-channel without any message level security might be sufficient. >> Most real world systems which use SAML or OpenID Connect only use bearer tokens, which could be intercepted and misused by a sufficiently powerful attacker. >> >> BR, >> Detlef >> >> >> Von:
dss-x@lists.oasis-open.org [ mailto:
dss-x@lists.oasis-open.org ] Im >> Auftrag von Frank Cornelis >> Gesendet: Montag, 29. Januar 2018 10:02 >> An: dss-x <
dss-x@lists.oasis-open.org> >> Betreff: Re: [dss-x] self-describing DSS-X instances >> >> Hi, >> >> As one of the goals of DSS 2 is "Support other transport formats than SOAP.", message-level security becomes a critical feature I guess. >> SOAP security is covered by WS-Security/WS-SecurityPolicy and such. A non-SOAP binding requires message-level security, obviously by means of XML signatures. >> >> I did some more experiments with message-level security. While this could be added in DSS 1, see: >> >>
https://www.e-contract.be/sites/dssp/dssp-specs/dssp-specs-1.5.1.pdf >> section 2.2 Browser POST, due to the AnyType being a base64 in Core 2: >> <dss:SignRequest xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema" xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" xmlns:ds="
http://www.w3.org/2000/09/xmldsig#" ;> >> <dss:OptionalInputs> >> <dsb:Other> >> <dsb:Value>d2hlcmUgZG8gSSBwdXQgbXkgWE1MIHNpZ25hdHVyZT8=</dsb:Value> >> </dsb:Other> >> </dss:OptionalInputs> >> </dss:SignRequest> >> it becomes impossible to express this. >> XML Signatures work at the DOM level, so we really need to be able to add "alien-namespace" XML elements. >> >> Besides the XML Signature issue, the parsing of additional profiles becomes a two-pass operation. >> In Core 1, you could add your additional profiles within your WSDL by means of a simple import. See example: >>
https://www.e-contract.be/sites/dssp/dssp-specs/dssp-ws.wsdl >> Feeding this to JAXWS/JAXB made it possible for JAXB to actually parse your additional profiles in one go. >> With the Core 2, you parse a first time towards base64, and then you have to run a second JAXB unmarshalling against this. From a usability/performance point-of-view, this becomes really painful. >> >> The structures intended to be supported by a client or a server system MUST be known to be implementable. But the usual tools for schema support leave the task of handling the content of an any type to the developer. Without extensive testing problems with unexpected content may occur at runtime, even while using typed languages. >> An AnyType of unknown namespace (in the context of the parser like JAWS/JAXB) simply results in a DOM element, as it should be. I don't see the problem here. >> Even if one would acknowledge this as a problem, doing a base64 is not solving anything at all. The problem remains. >> >> >> What am I missing here? >> >> >> I'm already managed to use Jackson for JSON Schema compilation in Java. Will play a bit with this AnyType stuff to see if the above issues could be resolved in a generic way to keep both XML and JSON happy. >> >> >> >> Kind Regards, >> Frank. >> >> >> On 01/28/2018 12:16 PM, Frank Cornelis wrote: >> Hi Andreas, >> >> >> Still have to get acquainted with the JSON Schema specs/tooling, but it seems like OASIS UBL solved a similar problem where both their XML and JSON have extension points, and their XML does it via xsd:any. >> See: >> >>
http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/csprd01/Busi >> ness-Document-NDR-v1.1-csprd01.html#S-EXTENSION-XML-SCHEMA-FRAGMENTS-A >> ND-DECLARATIONS >> And: >> >>
http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/csprd01/Busi >> ness-Document-NDR-v1.1-csprd01.html#S-EXTENSION-JSON-SCHEMA-FRAGMENTS- >> AND-DECLARATIONS >> >> >> BTW: In my “sandbox” project here, as part of my message-level security experiments, I also had to give the new Core 2 XSD a 2.0 namespace to be able to compile both Core 1 and Core 2 within the same Java Maven project. Core 2 will eventually receive a new namespace I guess? >> >> >> Kind Regards, >> Frank. >> >> >> Op 26 jan. 2018, om 19:47 heeft Andreas Kühne <
kuehne@trustable.de> het volgende geschreven: >> >> Hi Frank, >> >> thank you for your feedback! >> Yes, it’s an advantage to provide a sample WSDL as implementor’s support. But due to the support of current frameworks the WSDL slides towards being a derived artefact. >> >> I was assuming that the binding and the ‘annox’ namespaces, leaking thru from prior processing steps, are just irrelevant here. Interesting to see that these declarations do cause problems. Now I’ll drop them before reaching the final schema stage. Surprisingly no way to drop namespace declarations that are defined in the incoming document using XSLT … had to fall back to RegEx. >> >> Regarding the AnyType: >> The handy use case of putting some random XML fragment into an AnyType cannot be supported by the JSON syntax and vice versa. So the only feasible approach to transport arbitrary data _and_ supporting multiple syntaxes is to use some base64 encoded container. And we already have a fully featured Base64DataType defined in DSS (with a content describing MIME type attribute, support for references and attachments). So why not align all usages to the Base64DataType? >> >> The biggest pain point of the current multi-syntax approach is the effect on foreign schemes. As outlined in the new core draft, section 2.6, some well-respected features of XML cannot easily be mapped to e.g. JSON. So my current approach is to rewrite the referenced schemes and replace the XML specifics. Yes, bad approach but I don’t know of any better! Proposals welcome! >> >> Greetings, >> >> Andreas >> >> Von:
dss-x@lists.oasis-open.org [ mailto:
dss-x@lists.oasis-open.org ] Im >> Auftrag von Frank Cornelis >> Gesendet: Freitag, 26. Januar 2018 15:16 >> An:
dss-x@lists.oasis-open.org >> Betreff: Re: [dss-x] self-describing DSS-X instances >> >> Hi Andreas, >> >> Hereby some feedback on the XML schema and such. >> Why change AnyType exactly? >> >> Kind Regards, >> Frank. >> >> OASIS DSS Core 2 Remarks >> ======================== >> >> xml.xsd is missing from the ZIP. >> >> Always found it funny that there was no proper SOAP binding defined. See attachment for a first shot at it. >> >> >> === oasis-dss-core-schema-v1.0-os.xsd >> >> When trying to compile with JAX-WS I get: >> org.xml.sax.SAXParseException; systemId: file:/home/fcorneli/dssp-2/src/wsdl/oasis-dss-core-schema-v1.0-os.xsd; lineNumber: 1; columnNumber: 703; Unsupported binding namespace "
http://annox.dev.java.net" ;. Perhaps you meant "
http://java.sun.com/xml/ns/jaxb/xjc" ;? >> Had to remove: >> xmlns:annox="
http://annox.dev.java.net" ; >> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" >> >> === oasis-dss-base-schema-v2.0-os.xsd >> >> Same error here: >> org.xml.sax.SAXParseException; systemId: file:/home/fcorneli/dssp-2/src/wsdl/oasis-dss-base-schema-v2.0-os.xsd; lineNumber: 1; columnNumber: 555; Unsupported binding namespace "
http://annox.dev.java.net" ;. Perhaps you meant "
http://java.sun.com/xml/ns/jaxb/xjc" ;? >> So had to remove: >> xmlns:annox="
http://annox.dev.java.net" ; >> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" >> >> === xmldsig-core-schema.xsd >> >> This does not seem to be the original XMLDSig XML schema. >> Same error here: >> org.xml.sax.SAXParseException; systemId: file:/home/fcorneli/dssp-2/src/wsdl/xmldsig-core-schema.xsd; lineNumber: 23; columnNumber: 579; Unsupported binding namespace "
http://annox.dev.java.net" ;. Perhaps you meant "
http://java.sun.com/xml/ns/jaxb/xjc" ;? >> So had to remove: >> xmlns:annox="
http://annox.dev.java.net" ; >> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" >> >> === oasis-sstc-saml-schema-protocol-1.1.xsd >> >> This does not seem to be the original SAML 1.1 XML schema. >> org.xml.sax.SAXParseException; systemId: file:/home/fcorneli/dssp-2/src/wsdl/oasis-sstc-saml-schema-protocol-1.1.xsd; lineNumber: 1; columnNumber: 705; Unsupported binding namespace "
http://annox.dev.java.net" ;. Perhaps you meant "
http://java.sun.com/xml/ns/jaxb/xjc" ;? >> So had to remove: >> xmlns:annox="
http://annox.dev.java.net" ; >> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" >> >> >> On 01/24/2018 03:49 PM, Andreas Kuehne wrote: >> Hi Frank, >> >> good to see you re-joined DSS-X! >> >> Attached id the current core document reflecting our latest >> discussions regarding the dss:AnyType. In this version the AnyType is >> replaced by a Base64DataType. >> As you are interested in Remote Signing I added the schema of the >> ChipGateway profile, too. >> >> Greetings, >> >> Andreas >> Hi Andreas, >> >> >> Were can I find the 2.0 XML schema? >> >> I would like to check whether a "Remote Signature" profile with >> message-level integrity protection could be easily defined against the >> new 2.0 proposal. >> >> >> Kind Regards, >> Frank. >> >> >> On 01/24/2018 12:47 PM, Andreas Kuehne wrote: >> Hi all, >> >> >> the current version of the base schema includes a set of types to to >> self-decribe the DSS-X server instance (e.g. the DescriptionType). >> There are similiar concepts around, a popular one is HATEOS. >> >> So I would consider to separate this topic from the DSS-X specification. >> Like the TLS details included in core version 1.0 that outdated >> quickly the evolving area of instance meta information may render our >> specification effort useless. >> >> >> What's your view on this? >> >> Greetings, >> >> Andreas >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> > > -- > Frank Cornelis > e-Contract.be BVBA >
https://www.e-contract.be > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >