ipsec, esp: Which key is used to generate the HMAC The 2019 Stack Overflow Developer Survey Results Are In Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)What is the “shared secret” used for in IPSec VPN?What are the well known protocols that offer perfect forward secrecy?AES-GCM Hash sub key parameter in Intel's IPsec libraryIs IPsec IND-CCA secure provided the used block cipher is a pseudorandom function?where does the prime number taken in DH algorithm in IPSECWhy TLS uses in-band handshake signallingHow does OpenVPN work?
First use of “packing” as in carrying a gun
How to delete random line from file using Unix command?
Why can't wing-mounted spoilers be used to steepen approaches?
Would it be possible to rearrange a dragon's flight muscle to somewhat circumvent the square-cube law?
Windows 10: How to Lock (not sleep) laptop on lid close?
Typeface like Times New Roman but with "tied" percent sign
How to grep and cut numbers from a file and sum them
How does this infinite series simplify to an integral?
He got a vote 80% that of Emmanuel Macron’s
Can the prologue be the backstory of your main character?
Why does the Event Horizon Telescope (EHT) not include telescopes from Africa, Asia or Australia?
Derivation tree not rendering
Can the DM override racial traits?
Can a 1st-level character have an ability score above 18?
Did God make two great lights or did He make the great light two?
How did the audience guess the pentatonic scale in Bobby McFerrin's presentation?
Road tyres vs "Street" tyres for charity ride on MTB Tandem
Why can't devices on different VLANs, but on the same subnet, communicate?
How is simplicity better than precision and clarity in prose?
I could not break this equation. Please help me
Does Parliament hold absolute power in the UK?
Why not take a picture of a closer black hole?
Is above average number of years spent on PhD considered a red flag in future academia or industry positions?
Segmentation fault output is suppressed when piping stdin into a function. Why?
ipsec, esp: Which key is used to generate the HMAC
The 2019 Stack Overflow Developer Survey Results Are In
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)What is the “shared secret” used for in IPSec VPN?What are the well known protocols that offer perfect forward secrecy?AES-GCM Hash sub key parameter in Intel's IPsec libraryIs IPsec IND-CCA secure provided the used block cipher is a pseudorandom function?where does the prime number taken in DH algorithm in IPSECWhy TLS uses in-band handshake signallingHow does OpenVPN work?
$begingroup$
Short Question:
Are the keys for the ICV calculation and the encryption the same in IPSEC/ESP?
Or do there exist two keys in the SA?
Long Question:
Before a new IPSEC-ESP connection is established, IKEv2 is used to start a new session.
This involves also a DH key agreement.
This key is than stored in the IKE-SA.
Once the session is established, ESP uses the key in the IKE-SA's for the message encryption/decryption.
After the payload was encrypted, the ICV is calculated by a HMAC calculation.
But this HMAC requires also a key.
I have already searched for a few hours without being successful.
Is it the same key that is used for encryption, is it calculated out of the encryption key or are there two keys stored in the SA?
I wasn't able to find the answer in rfc4303 (ESP), rfc2104 (HMAC) or rfc7296 (IKEv2).
And there are not many books about IPsec out there.
ipsec
New contributor
$endgroup$
add a comment |
$begingroup$
Short Question:
Are the keys for the ICV calculation and the encryption the same in IPSEC/ESP?
Or do there exist two keys in the SA?
Long Question:
Before a new IPSEC-ESP connection is established, IKEv2 is used to start a new session.
This involves also a DH key agreement.
This key is than stored in the IKE-SA.
Once the session is established, ESP uses the key in the IKE-SA's for the message encryption/decryption.
After the payload was encrypted, the ICV is calculated by a HMAC calculation.
But this HMAC requires also a key.
I have already searched for a few hours without being successful.
Is it the same key that is used for encryption, is it calculated out of the encryption key or are there two keys stored in the SA?
I wasn't able to find the answer in rfc4303 (ESP), rfc2104 (HMAC) or rfc7296 (IKEv2).
And there are not many books about IPsec out there.
ipsec
New contributor
$endgroup$
add a comment |
$begingroup$
Short Question:
Are the keys for the ICV calculation and the encryption the same in IPSEC/ESP?
Or do there exist two keys in the SA?
Long Question:
Before a new IPSEC-ESP connection is established, IKEv2 is used to start a new session.
This involves also a DH key agreement.
This key is than stored in the IKE-SA.
Once the session is established, ESP uses the key in the IKE-SA's for the message encryption/decryption.
After the payload was encrypted, the ICV is calculated by a HMAC calculation.
But this HMAC requires also a key.
I have already searched for a few hours without being successful.
Is it the same key that is used for encryption, is it calculated out of the encryption key or are there two keys stored in the SA?
I wasn't able to find the answer in rfc4303 (ESP), rfc2104 (HMAC) or rfc7296 (IKEv2).
And there are not many books about IPsec out there.
ipsec
New contributor
$endgroup$
Short Question:
Are the keys for the ICV calculation and the encryption the same in IPSEC/ESP?
Or do there exist two keys in the SA?
Long Question:
Before a new IPSEC-ESP connection is established, IKEv2 is used to start a new session.
This involves also a DH key agreement.
This key is than stored in the IKE-SA.
Once the session is established, ESP uses the key in the IKE-SA's for the message encryption/decryption.
After the payload was encrypted, the ICV is calculated by a HMAC calculation.
But this HMAC requires also a key.
I have already searched for a few hours without being successful.
Is it the same key that is used for encryption, is it calculated out of the encryption key or are there two keys stored in the SA?
I wasn't able to find the answer in rfc4303 (ESP), rfc2104 (HMAC) or rfc7296 (IKEv2).
And there are not many books about IPsec out there.
ipsec
ipsec
New contributor
New contributor
New contributor
asked 6 hours ago
byteunitbyteunit
1062
1062
New contributor
New contributor
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
Are the keys for the ICV calculation and the encryption the same in IPSEC/ESP? Or do there exist two keys in the SA?
No, the keys are not the same. Yes, there do exist two keys in the SA (at least, for SAs that have separate encryption and integrity transforms - not all do).
You do derive both the encryption and the HMAC key at the same time, from the same secret, but they are not the same (that'd be bad key hygene). Instead they are derived from the same secret (and also you generate the keys for the SA protecting traffic flowing in the opposite direction at the same time).
That is, IKE generates a long random-looking string (which it refers to as KEYMAT); if the encryption key is n
bits and the integrity (ICV) key is m
bits (and AH is not being used), then at least 2n+2m bits of KEYMAT are generated, and then:
- The first n bits is used as the initiator-to-responder encryption key (that is, used to protect traffic flowing from the initiator to the responder)
- The next m bits is used as the initiator-to-responder integrity key
- The next n bits is used as the responder-to-initiator encryption key
- The next m bits is used as the responder-to-initiator integrity key
To see the text of the standard, see section 2.17 of RFC7296:
In any case, keying material
for each Child SA MUST be taken from the expanded KEYMAT using the
following rules:
All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator.
If multiple IPsec protocols are negotiated, keying material for
each Child SA is taken in the order in which the protocol headers
will appear in the encapsulated packet.
If an IPsec protocol requires multiple keys, the order in which
they are taken from the SA's keying material needs to be described
in the protocol's specification. For ESP and AH, [IPSECARCH]
defines the order, namely: the encryption key (if any) MUST be
taken from the first bits and the integrity key (if any) MUST be
taken from the remaining bits.
The HMAC key is the 'integrity key'
$endgroup$
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "281"
;
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
);
);
byteunit is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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%2fcrypto.stackexchange.com%2fquestions%2f68754%2fipsec-esp-which-key-is-used-to-generate-the-hmac%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
Are the keys for the ICV calculation and the encryption the same in IPSEC/ESP? Or do there exist two keys in the SA?
No, the keys are not the same. Yes, there do exist two keys in the SA (at least, for SAs that have separate encryption and integrity transforms - not all do).
You do derive both the encryption and the HMAC key at the same time, from the same secret, but they are not the same (that'd be bad key hygene). Instead they are derived from the same secret (and also you generate the keys for the SA protecting traffic flowing in the opposite direction at the same time).
That is, IKE generates a long random-looking string (which it refers to as KEYMAT); if the encryption key is n
bits and the integrity (ICV) key is m
bits (and AH is not being used), then at least 2n+2m bits of KEYMAT are generated, and then:
- The first n bits is used as the initiator-to-responder encryption key (that is, used to protect traffic flowing from the initiator to the responder)
- The next m bits is used as the initiator-to-responder integrity key
- The next n bits is used as the responder-to-initiator encryption key
- The next m bits is used as the responder-to-initiator integrity key
To see the text of the standard, see section 2.17 of RFC7296:
In any case, keying material
for each Child SA MUST be taken from the expanded KEYMAT using the
following rules:
All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator.
If multiple IPsec protocols are negotiated, keying material for
each Child SA is taken in the order in which the protocol headers
will appear in the encapsulated packet.
If an IPsec protocol requires multiple keys, the order in which
they are taken from the SA's keying material needs to be described
in the protocol's specification. For ESP and AH, [IPSECARCH]
defines the order, namely: the encryption key (if any) MUST be
taken from the first bits and the integrity key (if any) MUST be
taken from the remaining bits.
The HMAC key is the 'integrity key'
$endgroup$
add a comment |
$begingroup$
Are the keys for the ICV calculation and the encryption the same in IPSEC/ESP? Or do there exist two keys in the SA?
No, the keys are not the same. Yes, there do exist two keys in the SA (at least, for SAs that have separate encryption and integrity transforms - not all do).
You do derive both the encryption and the HMAC key at the same time, from the same secret, but they are not the same (that'd be bad key hygene). Instead they are derived from the same secret (and also you generate the keys for the SA protecting traffic flowing in the opposite direction at the same time).
That is, IKE generates a long random-looking string (which it refers to as KEYMAT); if the encryption key is n
bits and the integrity (ICV) key is m
bits (and AH is not being used), then at least 2n+2m bits of KEYMAT are generated, and then:
- The first n bits is used as the initiator-to-responder encryption key (that is, used to protect traffic flowing from the initiator to the responder)
- The next m bits is used as the initiator-to-responder integrity key
- The next n bits is used as the responder-to-initiator encryption key
- The next m bits is used as the responder-to-initiator integrity key
To see the text of the standard, see section 2.17 of RFC7296:
In any case, keying material
for each Child SA MUST be taken from the expanded KEYMAT using the
following rules:
All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator.
If multiple IPsec protocols are negotiated, keying material for
each Child SA is taken in the order in which the protocol headers
will appear in the encapsulated packet.
If an IPsec protocol requires multiple keys, the order in which
they are taken from the SA's keying material needs to be described
in the protocol's specification. For ESP and AH, [IPSECARCH]
defines the order, namely: the encryption key (if any) MUST be
taken from the first bits and the integrity key (if any) MUST be
taken from the remaining bits.
The HMAC key is the 'integrity key'
$endgroup$
add a comment |
$begingroup$
Are the keys for the ICV calculation and the encryption the same in IPSEC/ESP? Or do there exist two keys in the SA?
No, the keys are not the same. Yes, there do exist two keys in the SA (at least, for SAs that have separate encryption and integrity transforms - not all do).
You do derive both the encryption and the HMAC key at the same time, from the same secret, but they are not the same (that'd be bad key hygene). Instead they are derived from the same secret (and also you generate the keys for the SA protecting traffic flowing in the opposite direction at the same time).
That is, IKE generates a long random-looking string (which it refers to as KEYMAT); if the encryption key is n
bits and the integrity (ICV) key is m
bits (and AH is not being used), then at least 2n+2m bits of KEYMAT are generated, and then:
- The first n bits is used as the initiator-to-responder encryption key (that is, used to protect traffic flowing from the initiator to the responder)
- The next m bits is used as the initiator-to-responder integrity key
- The next n bits is used as the responder-to-initiator encryption key
- The next m bits is used as the responder-to-initiator integrity key
To see the text of the standard, see section 2.17 of RFC7296:
In any case, keying material
for each Child SA MUST be taken from the expanded KEYMAT using the
following rules:
All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator.
If multiple IPsec protocols are negotiated, keying material for
each Child SA is taken in the order in which the protocol headers
will appear in the encapsulated packet.
If an IPsec protocol requires multiple keys, the order in which
they are taken from the SA's keying material needs to be described
in the protocol's specification. For ESP and AH, [IPSECARCH]
defines the order, namely: the encryption key (if any) MUST be
taken from the first bits and the integrity key (if any) MUST be
taken from the remaining bits.
The HMAC key is the 'integrity key'
$endgroup$
Are the keys for the ICV calculation and the encryption the same in IPSEC/ESP? Or do there exist two keys in the SA?
No, the keys are not the same. Yes, there do exist two keys in the SA (at least, for SAs that have separate encryption and integrity transforms - not all do).
You do derive both the encryption and the HMAC key at the same time, from the same secret, but they are not the same (that'd be bad key hygene). Instead they are derived from the same secret (and also you generate the keys for the SA protecting traffic flowing in the opposite direction at the same time).
That is, IKE generates a long random-looking string (which it refers to as KEYMAT); if the encryption key is n
bits and the integrity (ICV) key is m
bits (and AH is not being used), then at least 2n+2m bits of KEYMAT are generated, and then:
- The first n bits is used as the initiator-to-responder encryption key (that is, used to protect traffic flowing from the initiator to the responder)
- The next m bits is used as the initiator-to-responder integrity key
- The next n bits is used as the responder-to-initiator encryption key
- The next m bits is used as the responder-to-initiator integrity key
To see the text of the standard, see section 2.17 of RFC7296:
In any case, keying material
for each Child SA MUST be taken from the expanded KEYMAT using the
following rules:
All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator.
If multiple IPsec protocols are negotiated, keying material for
each Child SA is taken in the order in which the protocol headers
will appear in the encapsulated packet.
If an IPsec protocol requires multiple keys, the order in which
they are taken from the SA's keying material needs to be described
in the protocol's specification. For ESP and AH, [IPSECARCH]
defines the order, namely: the encryption key (if any) MUST be
taken from the first bits and the integrity key (if any) MUST be
taken from the remaining bits.
The HMAC key is the 'integrity key'
edited 3 hours ago
answered 4 hours ago
ponchoponcho
94k2148247
94k2148247
add a comment |
add a comment |
byteunit is a new contributor. Be nice, and check out our Code of Conduct.
byteunit is a new contributor. Be nice, and check out our Code of Conduct.
byteunit is a new contributor. Be nice, and check out our Code of Conduct.
byteunit is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Cryptography 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.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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%2fcrypto.stackexchange.com%2fquestions%2f68754%2fipsec-esp-which-key-is-used-to-generate-the-hmac%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');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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