[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Namespace inheritance, other approach
Hi Trevor, please see below for a namespace (implementation) attack using a malicious client and reusing namespaces of the transport protocol and how to prevent that. Trevor Perrin wrote: > Konrad Lanz wrote: > [...] >> I'd say that a server should be very wary when signing data that uses >> prefixes defined by DSS and >> not having redeclared them inside the payload which is to be signed. >> I can imagine that this is very >> susceptible to attacks. > > Could you describe the attack? To be precise it is rather an attack on an incorrect implementation than on the protocol per se. > I understand that a client that doesn't redeclare prefixes inside the > payload might receive a signature on something he didn't intend. That is the point, and I would like to illustrate this further with an example and a few reasonable assumptions. Assuming someone uses the the dss prefix for a namespace like the following xmlns:dss="http://www.some-blacklist.com/disabled/server/signatures" and someone else uses a dss:KeySelector from the xmlns:dss="http://docs.oasis-open.org/dss/oasis-dss-1.0-core-schema-cd-02.xsd" namespace in a Signature. Now assume some system using signed dss:KeysSelectors from xmlns:dss="...disabled/server/signatures" that are excluded from trust, but signed dss:KeysSelectors from xmlns:dss="...oasis...." are trusted. Then <dss:XMLData> <dss:KeySelector xmlns:dss="http://www.some-blacklist.com/disallowed/server/signer/Keys"> [...] </dss:KeySelector> </dss:XMLData> is a lot different from <dss:XMLData> <dss:KeySelector> [...] </dss:KeySelector> </dss:XMLData> Essentially someone can use a malicious modified client to request a signature over a dss:KeySelector in a not redeclared namespace, thus essentially retrieving a signature over a dss:KeySelector in the namespace xmlns:dss="...oasis...." if the client by mistake losses original namespace context of the data. Then one can expect that exclusive canonicalization on the server side will do the job of adding xmlns:dss="...oasis....". > However, since the server canonicalizes before signing, the server > will always know what it is signing. One can argue that if you send the data without namespace redeclaration this is exactly what is intended and it should be interpreted as being in the outer namespace of the transport protocol in scope so the server only signs what it gets. Nevertheless this is not in an analogy to what would happen if the content was base64 encoded or if the signature was not created by dss. In the latter usually the complete DOM data structure also holding the xmlns:dss="...disabled/server/signatures" would still be available and not lost. However I think it is quite likely that this loss of information can happen in an implementation and hence opening an opportunity for an adversary. To prevent this loss it can be detected easily by the server and will be prevented by a requirement for XMLData to be free of any ancestry context. > So this is simply a broken > client getting broken results [...] That's the point and a suspicious (broken) client would get a questionable unanticipated (maybe ambiguous) result. I hope this makes sense. best regards Konrad P.S.: Consider the following examples and note that transmitting (I): <dss:XMLData> <dss:KeySelector> [...] </dss:KeySelector> </dss:XMLData> is equal to transmitting (II): <dss:XMLData> <dss:KeySelector xmlns:dss="http://docs.oasis-open.org/dss/oasis-dss-1.0-core-schema-cd-02.xsd"> [...] </dss:KeySelector> </dss:XMLData> which also is equal to (III): <XMLData xmlns="http://docs.oasis-open.org/dss/oasis-dss-1.0-core-schema-cd-02.xsd" xmlns:dss="http://docs.oasis-open.org/dss/oasis-dss-1.0-core-schema-cd-02.xsd"> <dss:KeySelector> [...] </dss:KeySelector> </XMLData> (I - III) require exclusive canonicalization of <dss:KeySelector> to produce equal digest inputs. But (I - III) are not the same as (IV): <dss:XMLData> <dss:KeySelector xmlns:dss="http://www.some-blacklist.com/disallowed/server/signer/Keys"> [...] </dss:KeySelector> </dss:XMLData> which in turn is however the same as transmitting (V): <XMLData xmlns="http://docs.oasis-open.org/dss/oasis-dss-1.0-core-schema-cd-02.xsd" xmlns:dss="http://www.some-blacklist.com/disallowed/server/signer/Keys"> <dss:KeySelector> [...] </dss:KeySelector> </XMLData> Valid redeclaration of namespaces (II,IV) could be achieved by exclusive canonicalization on the clientside which would have to be added at the end of the ds:Transforms already applied by the client to ensure that xmlns:dss="..." is always there. This however would impose a considerable burden on the client. Hence I would advocate for disallowing (I) and so forcing the client to consciously use namespaces in a clear way. Summarizing all this is guaranteed by ancestry context free XMLData and the tools will throw an exception if a prefix appears that has not been declared inside the payload or at least inside XMLData. I think it is also a lot clearer. Please see (II-V) for valid requests.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]