??? When we discussed the eIDs and the need of supplying
declarative information about the bearer of the hard token,
we encountered the problem of not knowing in advance which
services the eID will be used for. That lack of knowledge prevented
a proper encryption strategy of the declarative data. With
AS
B
TGS
TGS
B
KDC
AUTH
Want to Talk?
Ticket for Bob?
3
1
4
2 E
E
E
E
E
E
E
E
Figure 1-16 Kerberos authentication schema: Alice attempts to use the
Service B.
76 The Problem
the ticket model, the session keys are dynamically negotiated
every time; furthermore, the data about the user is handled directly
by the KDC. This means not only that we have a means of
circulating identity information on demand, but that we can also
make sure that every time the data will be encrypted to the exclusive
advantage of the intended recipient! We are really getting
close to solving many of the problems we encountered
so far.
Unfortunately, Kerberos is not the universal solution we are
looking for. Its omniscient KDC, the key pillar of the entire architecture,
is not a concept that scales to the Internet. Furthermore,
Kerberos is a fairly low-level protocol. Although all implementations
of it share the common ideas and architecture described
previously, many small differences and added-value services
make ready interoperability rather dif?¬?cult.
Pages:
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145