[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: protocol bindings
I summarised and somewhat formalized my views on protocol bindings.
I think this could clarify binding security consideration scope and related issues.
(At least for me)
1 Ht - transport protocol header
2 Mt - transport protocol message
3 Hb - bound protocol header
4 Mb - bound protocol message
5 H0 - protocol headers below bound protocol and above transport protocol
6
7 [e](k) - entity e encrypted with key k.
8 e'S(s) - entity e signed with key s.
9 (e1 e2 e3) - entity grouping
10
11 <e> - xml element
12 <S(s)> - xml digital signature (dsig:Signature) with key s.
13 <S(s, ref r)> - xml digital signature with key s and reference r.
14
15 Let's denote saml assertion as <SAML>.
16 Signed saml assertion would be: <SAML>'<S(s)>.
17 We understand this notation to say that saml assertion is signed
18 according to xml digital signature spec. We do not make any assumption
19 where in the saml message this signature is. It should be applied to
20 assertion in saml schema compliant way.
21
22 -- Examples.
23
24 1. Unprotected message in transit.
25 This case is not considered any more.
26 Ht Mt
27 Ht H0 Hb Mb
28
29 2. SSL-protected message in transit.
30 This message is signed and encrypted above transport layer.
31 Ht [ (H0 Hb Mb)'S(s) ](e)
32
33
34 -- Security considerations for protocol bindings.
35
36 Protocol bindings should be concerned with assertion integrity and
37 confidentiality as a unit in point to point communication.
38
39 It does not mean that saml assertion by itself should not be signed
40 or encrypted but this is the realm of saml security considerations.
41
42 Protocol bindings should not assume that the same key set is used
43 for ssl level protection, bound-protocol level protection,
44 and saml-level protection. We simply assume these keys are agreed upon
45 by issuing and relying parties.
46
47 Also, assertion relay is not in scope of protocol bindings. Ie we
48 do not consider cases like: ap -> rp, rp -> rp1, rp1 -> rp2, ...
49
50 Assertion exchange is fundamentally point-to-point procedure.
51 Hop-by-hop mechanisms of underlying protocols should be disabled
52 in protocol-specific way.
53
54
55 -- Http binding.
56
57 Http is bound directly to transport protocol (tcp), so H0 = 0.
58
59 ssl protected saml assertion. Saml assertion is not signed.
60 Ht [ ( Hb <SAML> )'S(s) ](e)
61
62 ssl protected saml assertion. Saml assertion is signed in saml
63 compliant way:
64 Ht [ ( Hb <SAML>'<S(s1)> )'S(s) ](e)
65
66 saml assertion encrypted with shared key:
67 Ht Hb [<SAML>](e)
68
69 Http binding precludes hop-by-hop http headers and disables caching.
70
71
72 -- Soap binding.
73
74 Soap is not directly bound to transport protocol. (it could be)
75
76 Soap specification allows for the intermidearies along the message
77 path.
78
79 Soap hop-by-hop headers should not be used.
80
81 Saml message is a specific case of soap body and thus could be
82 signed in soap-compliant way. I think this is the case of detached
83 digital signature.
84
85 So for the soap binding we have 3 levels at which saml message could
86 be signed: saml-compliant signature, soap-compliant signature, ssl
87 signature.
88
89 Soap binding should allow signing of saml message as a soap message.
90
91 Soap-compliant signature could be extracted by the soap layer and
92 either processed by it or passed along to the saml processing layer.
93
94 We have: Hb = <Sh>, Mb = <SAML>. We ignore soap envelope and soap
95 body for simplicity.
96
97 ssl protected soap message.
98 Ht [ ( H0 <Sh> <SAML> )'S(s) ](e)
99
100 ssl protected soap message. Saml message is signed in soap-compliant
101 way:
102 Ht [ ( H0 <Sh><S(s1,ref=saml)> <SAML> )'S(s) ](e)
103
104 ssl protected soap message. Saml message is signed in saml-compliant
105 way:
106 Ht [ ( H0 <Sh> <SAML>'<S(s1)> )'S(s) ](e)
107
108 ssl protected soap message. Saml message is signed in soap and saml
109 compliant ways:
110 Ht [ ( H0 <Sh><S(s1,ref=saml)> <SAML>'<S(s2)> )'S(s) ](e)
111
112 saml assertion encrypted with shared key:
113 Ht H0 <Sh> [SAML](e)
114
115
116 -- Saml soap profile.
117
118 Saml assertion should be passed in saml header signed in saml-compliant
119 way.
120
121 ssl protected soap message with embedded saml assertion:
122 Ht [ ( H0 <Sh><SAML>'S<s1> <Sb> )'S(s) ](e)
Simon Godik
Crosslogix, Inc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC