Lines Matching full:var

65 they claim to be. In the following example, @var{A} is the initiator of
66 the authentication exchange, usually a user, and @var{B} is the service
67 that @var{A} wishes to use.
69 To obtain a ticket for a specific service, @var{A} sends a ticket
70 request to the kerberos server. The request contains @var{A}'s and
71 @var{B}'s names (along with some other fields). The kerberos server
72 checks that both @var{A} and @var{B} are valid principals.
75 containing @var{A}'s and @var{B}'s names, @var{A}'s network address
76 (@var{A@sub{addr}}), the current time (@var{t@sub{issue}}), the lifetime
77 of the ticket (@var{life}), and a secret @dfn{session key}
79 (@var{K@sub{AB}}). This packet is encrypted with @var{B}'s secret key
80 (@var{K@sub{B}}).  The actual ticket (@var{T@sub{AB}}) looks like this:
81 (@{@var{A}, @var{B}, @var{A@sub{addr}}, @var{t@sub{issue}}, @var{life},
82 @var{K@sub{AB}}@}@var{K@sub{B}}).
84 The reply to @var{A} consists of the ticket (@var{T@sub{AB}}), @var{B}'s
86 encrypted in @var{A}'s secret key (@{@var{B}, @var{t@sub{issue}},
87 @var{life}, @var{K@sub{AB}}, @var{T@sub{AB}}@}@var{K@sub{A}}). @var{A}
92 Before sending a message to @var{B}, @var{A} creates an authenticator
93 consisting of @var{A}'s name, @var{A}'s address, the current time, and a
94 ``checksum'' chosen by @var{A}, all encrypted with the secret session
95 key (@{@var{A}, @var{A@sub{addr}}, @var{t@sub{current}},
96 @var{checksum}@}@var{K@sub{AB}}). This is sent together with the ticket
97 received from the kerberos server to @var{B}.  Upon reception, @var{B}
98 decrypts the ticket using @var{B}'s secret key.  Since the ticket
100 @var{B} can now also decrypt the authenticator. To verify that @var{A}
101 really is @var{A}, @var{B} now has to compare the contents of the ticket
102 with that of the authenticator. If everything matches, @var{B} now
103 considers @var{A} as properly authenticated.
111 An impostor, @var{C} could steal the authenticator and the ticket as it
113 @var{A}. The address in the ticket and the authenticator was added to
114 make it more difficult to perform this attack.  To succeed @var{C} will
115 have to either use the same machine as @var{A} or fake the source
117 authenticator, @var{C} does not have much time in which to mount the
122 @var{C} can hijack @var{B}'s network address, and when @var{A} sends
123 her credentials, @var{C} just pretend to verify them. @var{C} can't
124 be sure that she is talking to @var{A}.
131 the last few minutes, so that @var{B} can detect when someone is trying
136 To authenticate @var{B}, @var{A} might request that @var{B} sends
137 something back that proves that @var{B} has access to the session
138 key. An example of this is the checksum that @var{A} sent as part of the
140 encrypt it with the session key and send it back to @var{A}.  This is
144 messages sent between @var{A} and @var{B} (known as @dfn{message