Are there use cases where a mutually authenticated TLS is preferred?
I am trying to see if there are use cases where a mutually authenticated TLS is preferred over a one way authentication.
Usually the authentication of the client/user is done over the TLS tunnel.
Is a p2p connection a good use case for mutual authentication? In such a scenario each end will somehow prove that they are part of the network. However, in this case the authentication/verification can happen over a one-way authenticated tunnel. What would mandate a mutual auth here?
Are there any other cases I am missing?
tls authentication
add a comment |
I am trying to see if there are use cases where a mutually authenticated TLS is preferred over a one way authentication.
Usually the authentication of the client/user is done over the TLS tunnel.
Is a p2p connection a good use case for mutual authentication? In such a scenario each end will somehow prove that they are part of the network. However, in this case the authentication/verification can happen over a one-way authenticated tunnel. What would mandate a mutual auth here?
Are there any other cases I am missing?
tls authentication
add a comment |
I am trying to see if there are use cases where a mutually authenticated TLS is preferred over a one way authentication.
Usually the authentication of the client/user is done over the TLS tunnel.
Is a p2p connection a good use case for mutual authentication? In such a scenario each end will somehow prove that they are part of the network. However, in this case the authentication/verification can happen over a one-way authenticated tunnel. What would mandate a mutual auth here?
Are there any other cases I am missing?
tls authentication
I am trying to see if there are use cases where a mutually authenticated TLS is preferred over a one way authentication.
Usually the authentication of the client/user is done over the TLS tunnel.
Is a p2p connection a good use case for mutual authentication? In such a scenario each end will somehow prove that they are part of the network. However, in this case the authentication/verification can happen over a one-way authenticated tunnel. What would mandate a mutual auth here?
Are there any other cases I am missing?
tls authentication
tls authentication
asked Jan 22 at 19:25
SFlowSFlow
4815
4815
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
There's a lot of potential benefits to mutual authentication using TLS. Here's a few.
You don't need to keep a username/pass database
No worry about password reuse.
Credentials can be stored on physical tokens/devices.
Credentials aren't going to be written on post-it.
Users don't have to enter credentials when visiting your resource (certs are automatically used).
Less concern about TLS interception proxies as you're authenticating the client.
There's little chance of brute forcing a certificate (no worry of password dictionary/brute force)
You would then be reliant on a centralized authority to issue or sign your certificates.
I would add that user database is still required to map peer certificates against.
– Crypt32
Jan 22 at 20:34
I see what you mean, but depending on the use case you might not need a username database. If your only concern is authentication, not authorization (you only care that they are a valid user, not who they are) then a username/profile DB isn't needed.
– Daisetsu
Jan 22 at 20:41
you only care that they are a valid user
-- this require a users database. How you can tell if presented certificate came from valid user and you have enough information to authenticate them?
– Crypt32
Jan 22 at 21:06
If their certificate validates, and has not been revoked.
– Daisetsu
Jan 22 at 21:07
1
@Crypt32: if you have your own PKI and have full control over the issued client certificates you can just put the username in the certificate. You don't need an additional mapping between certificate and user since the username can be directly extracted from the certificate.
– Steffen Ullrich
Jan 22 at 22:02
|
show 2 more comments
Embedded software that automatically connects to a secure server is an example that immediately comes to mind.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201973%2fare-there-use-cases-where-a-mutually-authenticated-tls-is-preferred%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
There's a lot of potential benefits to mutual authentication using TLS. Here's a few.
You don't need to keep a username/pass database
No worry about password reuse.
Credentials can be stored on physical tokens/devices.
Credentials aren't going to be written on post-it.
Users don't have to enter credentials when visiting your resource (certs are automatically used).
Less concern about TLS interception proxies as you're authenticating the client.
There's little chance of brute forcing a certificate (no worry of password dictionary/brute force)
You would then be reliant on a centralized authority to issue or sign your certificates.
I would add that user database is still required to map peer certificates against.
– Crypt32
Jan 22 at 20:34
I see what you mean, but depending on the use case you might not need a username database. If your only concern is authentication, not authorization (you only care that they are a valid user, not who they are) then a username/profile DB isn't needed.
– Daisetsu
Jan 22 at 20:41
you only care that they are a valid user
-- this require a users database. How you can tell if presented certificate came from valid user and you have enough information to authenticate them?
– Crypt32
Jan 22 at 21:06
If their certificate validates, and has not been revoked.
– Daisetsu
Jan 22 at 21:07
1
@Crypt32: if you have your own PKI and have full control over the issued client certificates you can just put the username in the certificate. You don't need an additional mapping between certificate and user since the username can be directly extracted from the certificate.
– Steffen Ullrich
Jan 22 at 22:02
|
show 2 more comments
There's a lot of potential benefits to mutual authentication using TLS. Here's a few.
You don't need to keep a username/pass database
No worry about password reuse.
Credentials can be stored on physical tokens/devices.
Credentials aren't going to be written on post-it.
Users don't have to enter credentials when visiting your resource (certs are automatically used).
Less concern about TLS interception proxies as you're authenticating the client.
There's little chance of brute forcing a certificate (no worry of password dictionary/brute force)
You would then be reliant on a centralized authority to issue or sign your certificates.
I would add that user database is still required to map peer certificates against.
– Crypt32
Jan 22 at 20:34
I see what you mean, but depending on the use case you might not need a username database. If your only concern is authentication, not authorization (you only care that they are a valid user, not who they are) then a username/profile DB isn't needed.
– Daisetsu
Jan 22 at 20:41
you only care that they are a valid user
-- this require a users database. How you can tell if presented certificate came from valid user and you have enough information to authenticate them?
– Crypt32
Jan 22 at 21:06
If their certificate validates, and has not been revoked.
– Daisetsu
Jan 22 at 21:07
1
@Crypt32: if you have your own PKI and have full control over the issued client certificates you can just put the username in the certificate. You don't need an additional mapping between certificate and user since the username can be directly extracted from the certificate.
– Steffen Ullrich
Jan 22 at 22:02
|
show 2 more comments
There's a lot of potential benefits to mutual authentication using TLS. Here's a few.
You don't need to keep a username/pass database
No worry about password reuse.
Credentials can be stored on physical tokens/devices.
Credentials aren't going to be written on post-it.
Users don't have to enter credentials when visiting your resource (certs are automatically used).
Less concern about TLS interception proxies as you're authenticating the client.
There's little chance of brute forcing a certificate (no worry of password dictionary/brute force)
You would then be reliant on a centralized authority to issue or sign your certificates.
There's a lot of potential benefits to mutual authentication using TLS. Here's a few.
You don't need to keep a username/pass database
No worry about password reuse.
Credentials can be stored on physical tokens/devices.
Credentials aren't going to be written on post-it.
Users don't have to enter credentials when visiting your resource (certs are automatically used).
Less concern about TLS interception proxies as you're authenticating the client.
There's little chance of brute forcing a certificate (no worry of password dictionary/brute force)
You would then be reliant on a centralized authority to issue or sign your certificates.
edited Jan 22 at 19:42
answered Jan 22 at 19:36
DaisetsuDaisetsu
4,10711021
4,10711021
I would add that user database is still required to map peer certificates against.
– Crypt32
Jan 22 at 20:34
I see what you mean, but depending on the use case you might not need a username database. If your only concern is authentication, not authorization (you only care that they are a valid user, not who they are) then a username/profile DB isn't needed.
– Daisetsu
Jan 22 at 20:41
you only care that they are a valid user
-- this require a users database. How you can tell if presented certificate came from valid user and you have enough information to authenticate them?
– Crypt32
Jan 22 at 21:06
If their certificate validates, and has not been revoked.
– Daisetsu
Jan 22 at 21:07
1
@Crypt32: if you have your own PKI and have full control over the issued client certificates you can just put the username in the certificate. You don't need an additional mapping between certificate and user since the username can be directly extracted from the certificate.
– Steffen Ullrich
Jan 22 at 22:02
|
show 2 more comments
I would add that user database is still required to map peer certificates against.
– Crypt32
Jan 22 at 20:34
I see what you mean, but depending on the use case you might not need a username database. If your only concern is authentication, not authorization (you only care that they are a valid user, not who they are) then a username/profile DB isn't needed.
– Daisetsu
Jan 22 at 20:41
you only care that they are a valid user
-- this require a users database. How you can tell if presented certificate came from valid user and you have enough information to authenticate them?
– Crypt32
Jan 22 at 21:06
If their certificate validates, and has not been revoked.
– Daisetsu
Jan 22 at 21:07
1
@Crypt32: if you have your own PKI and have full control over the issued client certificates you can just put the username in the certificate. You don't need an additional mapping between certificate and user since the username can be directly extracted from the certificate.
– Steffen Ullrich
Jan 22 at 22:02
I would add that user database is still required to map peer certificates against.
– Crypt32
Jan 22 at 20:34
I would add that user database is still required to map peer certificates against.
– Crypt32
Jan 22 at 20:34
I see what you mean, but depending on the use case you might not need a username database. If your only concern is authentication, not authorization (you only care that they are a valid user, not who they are) then a username/profile DB isn't needed.
– Daisetsu
Jan 22 at 20:41
I see what you mean, but depending on the use case you might not need a username database. If your only concern is authentication, not authorization (you only care that they are a valid user, not who they are) then a username/profile DB isn't needed.
– Daisetsu
Jan 22 at 20:41
you only care that they are a valid user
-- this require a users database. How you can tell if presented certificate came from valid user and you have enough information to authenticate them?– Crypt32
Jan 22 at 21:06
you only care that they are a valid user
-- this require a users database. How you can tell if presented certificate came from valid user and you have enough information to authenticate them?– Crypt32
Jan 22 at 21:06
If their certificate validates, and has not been revoked.
– Daisetsu
Jan 22 at 21:07
If their certificate validates, and has not been revoked.
– Daisetsu
Jan 22 at 21:07
1
1
@Crypt32: if you have your own PKI and have full control over the issued client certificates you can just put the username in the certificate. You don't need an additional mapping between certificate and user since the username can be directly extracted from the certificate.
– Steffen Ullrich
Jan 22 at 22:02
@Crypt32: if you have your own PKI and have full control over the issued client certificates you can just put the username in the certificate. You don't need an additional mapping between certificate and user since the username can be directly extracted from the certificate.
– Steffen Ullrich
Jan 22 at 22:02
|
show 2 more comments
Embedded software that automatically connects to a secure server is an example that immediately comes to mind.
add a comment |
Embedded software that automatically connects to a secure server is an example that immediately comes to mind.
add a comment |
Embedded software that automatically connects to a secure server is an example that immediately comes to mind.
Embedded software that automatically connects to a secure server is an example that immediately comes to mind.
answered Jan 22 at 21:31
BenBen
2,959618
2,959618
add a comment |
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201973%2fare-there-use-cases-where-a-mutually-authenticated-tls-is-preferred%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown