Newer
Older
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
that service in that domain, with an user in the \textit{domain.com} realm.\\
The client manager will now handle the rest, and give back to the application only the encryption keys.
The first thing the client manager does is to inform the user that the application \textit{X} has requested access to the specified service at \textit{domain.com},
and that the application will use the account the application has requested.
If the user accepts, the client manager will now:
\begin{enumerate}
\item ask the AS of \textit{example.com} for a token for the specified service and username at \textit{domain.com}
\item resolv \textit{domain.com} authentication server, and gets its key and info
\item resolv the service the application wants to connect to to get its private key.
\item connect to \textit{domain.com} AS, provide the previous token as proof of authentication
\end{enumerate}
It should be noted that step 1, 2 and 3 can be done in parallel to improve efficiency and that step 1 is only needed the first time the client manager
connect to the service, as the token can be cached.
On the other side, the authentication server for \textit{domain.com} receives a request for an authentication. The contents will be the user in the
\textit{domain.com} realm, the user in the \textit{example.com} (which can be a temporary username), and a token. The AS will now check
the token with the AS for \textit{example.com}, giving it the usernames, token and service id as received by the client manager, and in case of a successful
answer it will inform the right service that a new user has connected.
As this point the service will generate a new connection id, a new key. Two things can happen.\\
If the two have a shared OTP:
\begin{itemize}
\item the service XORs the key with the current OTP hash
\item the service sends the XORed key, hash iteration number, connection id to the authentication server.
\item the AS relays them to the client manager.
\item the client manager computes the key and previous OTP hash iteration, and gives it to the application
\item the application can now connect to the service with a shared key and without MITM from even the ASs
\end{itemize}
But on the first connection, the client does not have any shared secret, so in this case the client manager will generate a private/public key of the same
type as the service's one. This key will be transmitted during authentication, along with the encrypted, hashed OTP and the number of iterations in the hash.
The service will use the public key to generate the shared secret and decrypt the OTP, and then resume normal flow.
~\\
The XOR between the encryption keys and the user OTP will grant secrecy of the session keys. Due to both the key and the OTP being completely random,
there will be no way of recovering the session keys, even if a Vigenère like XOR is applied, and will thus prevent MITM even from the authentication servers.