headers
Yoav Nir | 2 Apr 2008 12:48
Picon
Favicon

Fwd: I-D Action:draft-nir-ike-qcd-00.txt

Hi all

This is the second draft (with a title change) of my draft for quick  
discovery of a rebooted peer.

In this version I've changed the following:
- Changed "Quick Crash Recovery" to "Quick Crash Detection"
- Added interaction with IFARE
- Added discussion of backup gateways, whether IFARE type or high- 
availability cluster configurations.

Your comments are most welcome

Yoav

Begin forwarded message:
> From: Internet-Drafts <at> ietf.org
> Date: April 2, 2008 10:45:02 AM GMT+03:00
> To: i-d-announce <at> ietf.org
> Subject: I-D Action:draft-nir-ike-qcd-00.txt
> Reply-To: internet-drafts <at> ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : A Quick Crash Detection Method for IKE
> 	Author(s)       : Y. Nir
> 	Filename        : draft-nir-ike-qcd-00.txt
> 	Pages           : 15
> 	Date            : 2008-04-02
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Lawless | 2 Apr 2008 21:08

AH ICV calculation

Hi all,

We are in the process of implementing static keyed IPSec for the IPv6 
portion of a commercial TCP/IP stack and are having problems computing 
the AH ICV correctly.  Using NULL as the authentication type there are 
no problems communicating with other hosts (Windows XP) so I have ruled 
out problems with packet decoding, SPI assignment, etc.  However, using 
any HMAC algorithm (MD5-96 or SHA1-96) the calculated ICV never 
matches.  I should also note that the HMAC algorithm we are using works 
correctly with our TLS 1.0 implementation and so I feel we can rule out 
HMAC and MD5/SHA1 algorithms as the problem.

The ICV calculation matches if I test one Windows XP machine against 
another or one of our development boards running our stack against 
another.  This means our ICV calculation is consistent (but incorrect) 
upon inbound and outbound processing.  I have read through the NetBSD 
code (ah_core.c) and cannot find any difference in how they are muting 
the IPv6 header fields vs. how we are...

I have walked us through an example below that uses MD5 as the AH 
algorithm with our implementation receiving an ICMPv6 ping from a 
Windows XP host with outbound SPI 3001 (0x00000BB9), configured with 
HMAC-MD5-96 and key file "0123456789ABCDEF":

Complete ICMPv6 packet captured with Ethereal:

0000   00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00  ...T....`..>..`.
0010   00 00 00 40 33 80 fe 80 00 00 00 00 00 00 02 1d  ... <at> 3...........
0020   60 ff fe 0d 97 3e fe 80 00 00 00 00 00 00 02 00  `....>..........
0030   00 ff fe 54 85 00 3a 04 00 00 00 00 0b b9 00 00  ...T..:.........
(Continue reading)

Permalink | Reply | 3 comments |
headers
Scott C Moonen | 3 Apr 2008 15:40
Picon
Favicon

Re: AH ICV calculation


Hi Sean.  Please take the following with a grain of salt, because it is relayed secondhand, from a year or two ago, and the original tester is actually no longer with our company.  Our system test group was able to successfully implement dynamic SAs between our platform and Microsoft Windows.  One of our testers had some problems, however, configuring manual SAs between our platform and Windows.  We got the impression at the time that Windows doesn't directly use the key data that you enter in its configuration, but that it somehow hashes it to produce the actual key for the SA.  My recollection (could be wrong) is that he was able to enter key values longer than 16 bytes on Windows for various algorithms (both HMAC-x and encryption algorithms), and this may have been what led us to conclude that the key was derived from what he entered rather than being exactly what he entered.

We couldn't find any documentation on how the keys are derived, and I don't know whether he pursued an answer from Microsoft support.  I suspect that he never got manual keys working.  It wasn't a high priority test in his case since we were able to successfully interact with numerous other platforms using manual SAs.  At very least, we don't currently have any manual SAs in our testbed between our platform and Windows (though we do have dynamic SAs).

So you might consider trying your test with another platform than Windows; perhaps Linux or Cisco.  Alternatively, you might consider contacting Microsoft (or perhaps a Microsoft representative will comment in response to this) to understand how their implementation derives keys for manual SAs.  Lastly, you might consider dynamic SAs, though I realize that this may not be a trivial exercise. :)

For what it's worth, with a quick seat-of-the-pants calculation I did arrive at the same ICV value for your sample data that you obtained.  That doesn't mean that you and I aren't making the same oversight. :)


Scott Moonen (smoonen <at> us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen


From: Sean Lawless <sean <at> blunkmicro.com>
To: ipsec <at> ietf.org
Date: 04/02/2008 03:16 PM
Subject: [IPsec] AH ICV calculation




Hi all,

We are in the process of implementing static keyed IPSec for the IPv6
portion of a commercial TCP/IP stack and are having problems computing
the AH ICV correctly.  Using NULL as the authentication type there are
no problems communicating with other hosts (Windows XP) so I have ruled
out problems with packet decoding, SPI assignment, etc.  However, using
any HMAC algorithm (MD5-96 or SHA1-96) the calculated ICV never
matches.  I should also note that the HMAC algorithm we are using works
correctly with our TLS 1.0 implementation and so I feel we can rule out
HMAC and MD5/SHA1 algorithms as the problem.

The ICV calculation matches if I test one Windows XP machine against
another or one of our development boards running our stack against
another.  This means our ICV calculation is consistent (but incorrect)
upon inbound and outbound processing.  I have read through the NetBSD
code (ah_core.c) and cannot find any difference in how they are muting
the IPv6 header fields vs. how we are...

I have walked us through an example below that uses MD5 as the AH
algorithm with our implementation receiving an ICMPv6 ping from a
Windows XP host with outbound SPI 3001 (0x00000BB9), configured with
HMAC-MD5-96 and key file "0123456789ABCDEF":

Complete ICMPv6 packet captured with Ethereal:

0000   00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00  ...T....`..>..`.
0010   00 00 00 40 33 80 fe 80 00 00 00 00 00 00 02 1d  ... <at> 3...........
0020   60 ff fe 0d 97 3e fe 80 00 00 00 00 00 00 02 00  `....>..........
0030   00 ff fe 54 85 00 3a 04 00 00 00 00 0b b9 00 00  ...T..:.........
0040   00 07 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a 80 00  ..1..?.m.X......
0050   59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6a  Y3....abcdefghij
0060   6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63  klmnopqrstuvwabc
0070   64 65 66 67 68 69                                defghi

Packet after mutable field hop limit and ICV are zero'd:

0000   00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00
0010   00 00 00 40 33 00 FE 80 00 00 00 00 00 00 02 1D
0020   60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 02 00
0030   00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 00 00
0040   00 07 00 00 00 00 00 00 00 00 00 00 00 00 80 00
0050   59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6A
0060   6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63
0070   64 65 66 67 68 69

The manual key being used is "0123456789ABCDEF" which has a key length
of 16.  After the HMAC init function is called with the key and key
length, the packet is processed with HMAC-MD5.  There are 104 bytes
processed from packet offset 000E to 0075:

60 00 00 00 00 40 33 00 FE 80 00 00 00 00 00 00
02 1D 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00
02 00 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9
00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00
80 00 59 33 00 00 00 07 61 62 63 64 65 66 67 68
69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61
62 63 64 65 66 67 68 69

After the HMAC calculation is finished, the first 96 bits of the hash of
the above data is:

70 14 6d d1 15 4c 85 2c 26 a7 31 68

Which does not match the ICV in the packet:

31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a

I have double checked and the HMAC-MD5-96 hash we calculated is correct
for the key and data being processed, therefore I can only assume that
the data we are processing is incorrect (or the manual key requires
preprocessing?).  I've reread the RFCs many times and am at a loss for
what could be the problem.  Can anyone spot what I am doing wrong?  Also
it would be very helpful to me if anyone could point to an example of AH
processing on an actual packet.  Something similar to the steps outlined
above?

Best Regards,

Sean Lawless
Blunk Microsystems LLC
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 2 comments |
headers
Sean Lawless | 3 Apr 2008 20:52

Re: AH ICV calculation

Thanks Scott, your response was helpful.  I previously read this thread 
on the web about Win2003 and Kame and then assumed that Windows was not 
doing anything special and would interoperate:

http://atm.tut.fi/list-archive/snap-users/msg03001.html

It sounds like this may not be a safe assumption but I sure wish someone 
at Microsoft would comment about this.  Has anyone successfully 
interop'ed static keyed Window IPv6 
(http://msdn2.microsoft.com/en-us/library/ms737602.aspx) with Kame or 
another IPSec implementation?  If not my next step must be to test with 
another implementation.

Thanks for the help,
Sean

Scott C Moonen wrote:
>
> Hi Sean.  Please take the following with a grain of salt, because it 
> is relayed secondhand, from a year or two ago, and the original tester 
> is actually no longer with our company.  Our system test group was 
> able to successfully implement dynamic SAs between our platform and 
> Microsoft Windows.  One of our testers had some problems, however, 
> configuring manual SAs between our platform and Windows.  We got the 
> impression at the time that Windows doesn't directly use the key data 
> that you enter in its configuration, but that it somehow hashes it to 
> produce the actual key for the SA.  My recollection (could be wrong) 
> is that he was able to enter key values longer than 16 bytes on 
> Windows for various algorithms (both HMAC-x and encryption 
> algorithms), and this may have been what led us to conclude that the 
> key was derived from what he entered rather than being exactly what he 
> entered.
>
> We couldn't find any documentation on how the keys are derived, and I 
> don't know whether he pursued an answer from Microsoft support.  I 
> suspect that he never got manual keys working.  It wasn't a high 
> priority test in his case since we were able to successfully interact 
> with numerous other platforms using manual SAs.  At very least, we 
> don't currently have any manual SAs in our testbed between our 
> platform and Windows (though we do have dynamic SAs).
>
> So you might consider trying your test with another platform than 
> Windows; perhaps Linux or Cisco.  Alternatively, you might consider 
> contacting Microsoft (or perhaps a Microsoft representative will 
> comment in response to this) to understand how their implementation 
> derives keys for manual SAs.  Lastly, you might consider dynamic SAs, 
> though I realize that this may not be a trivial exercise. :)
>
> For what it's worth, with a quick seat-of-the-pants calculation I did 
> arrive at the same ICV value for your sample data that you obtained. 
>  That doesn't mean that you and I aren't making the same oversight. :)
>
>
> Scott Moonen (smoonen <at> us.ibm.com)
> z/OS Communications Server TCP/IP Development
> http://scott.andstuff.org/
> http://www.linkedin.com/in/smoonen
>
>
> From: 	Sean Lawless <sean <at> blunkmicro.com>
> To: 	ipsec <at> ietf.org
> Date: 	04/02/2008 03:16 PM
> Subject: 	[IPsec] AH ICV calculation
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi all,
>
> We are in the process of implementing static keyed IPSec for the IPv6
> portion of a commercial TCP/IP stack and are having problems computing
> the AH ICV correctly.  Using NULL as the authentication type there are
> no problems communicating with other hosts (Windows XP) so I have ruled
> out problems with packet decoding, SPI assignment, etc.  However, using
> any HMAC algorithm (MD5-96 or SHA1-96) the calculated ICV never
> matches.  I should also note that the HMAC algorithm we are using works
> correctly with our TLS 1.0 implementation and so I feel we can rule out
> HMAC and MD5/SHA1 algorithms as the problem.
>
> The ICV calculation matches if I test one Windows XP machine against
> another or one of our development boards running our stack against
> another.  This means our ICV calculation is consistent (but incorrect)
> upon inbound and outbound processing.  I have read through the NetBSD
> code (ah_core.c) and cannot find any difference in how they are muting
> the IPv6 header fields vs. how we are...
>
> I have walked us through an example below that uses MD5 as the AH
> algorithm with our implementation receiving an ICMPv6 ping from a
> Windows XP host with outbound SPI 3001 (0x00000BB9), configured with
> HMAC-MD5-96 and key file "0123456789ABCDEF":
>
> Complete ICMPv6 packet captured with Ethereal:
>
> 0000   00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00  ...T....`..>..`.
> 0010   00 00 00 40 33 80 fe 80 00 00 00 00 00 00 02 1d  ... <at> 3...........
> 0020   60 ff fe 0d 97 3e fe 80 00 00 00 00 00 00 02 00  `....>..........
> 0030   00 ff fe 54 85 00 3a 04 00 00 00 00 0b b9 00 00  ...T..:.........
> 0040   00 07 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a 80 00  ..1..?.m.X......
> 0050   59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6a  Y3....abcdefghij
> 0060   6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63  klmnopqrstuvwabc
> 0070   64 65 66 67 68 69                                defghi
>
> Packet after mutable field hop limit and ICV are zero'd:
>
> 0000   00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00
> 0010   00 00 00 40 33 00 FE 80 00 00 00 00 00 00 02 1D
> 0020   60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 02 00
> 0030   00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 00 00
> 0040   00 07 00 00 00 00 00 00 00 00 00 00 00 00 80 00
> 0050   59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6A
> 0060   6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63
> 0070   64 65 66 67 68 69
>
> The manual key being used is "0123456789ABCDEF" which has a key length
> of 16.  After the HMAC init function is called with the key and key
> length, the packet is processed with HMAC-MD5.  There are 104 bytes
> processed from packet offset 000E to 0075:
>
> 60 00 00 00 00 40 33 00 FE 80 00 00 00 00 00 00
> 02 1D 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00
> 02 00 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9
> 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00
> 80 00 59 33 00 00 00 07 61 62 63 64 65 66 67 68
> 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61
> 62 63 64 65 66 67 68 69
>
> After the HMAC calculation is finished, the first 96 bits of the hash of
> the above data is:
>
> 70 14 6d d1 15 4c 85 2c 26 a7 31 68
>
> Which does not match the ICV in the packet:
>
> 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a
>
> I have double checked and the HMAC-MD5-96 hash we calculated is correct
> for the key and data being processed, therefore I can only assume that
> the data we are processing is incorrect (or the manual key requires
> preprocessing?).  I've reread the RFCs many times and am at a loss for
> what could be the problem.  Can anyone spot what I am doing wrong?  Also
> it would be very helpful to me if anyone could point to an example of AH
> processing on an actual packet.  Something similar to the steps outlined
> above?
>
> Best Regards,
>
> Sean Lawless
> Blunk Microsystems LLC
> _______________________________________________
> IPsec mailing list
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> IPsec mailing list
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
Permalink | Reply | 1 comment |
headers
Paul Hoffman | 4 Apr 2008 05:29

Re: Bug: Section 2.15 - Responder Signed Octets

I'm cleaning up some IKEv2bis issues, and noticed this one had not 
been replied to. Does everyone agree that this change is correct?

--Paul Hoffman

At 2:17 PM -0800 3/6/08, Jeffrey Sun wrote:
>Current:
>
>The responder's signed octets can be described as:
>
>    ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
>    GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
>    RealIKEHDR =  SPIi | SPIr |  . . . | Length
>    RealMessage2 = RealIKEHDR | RestOfMessage2
>    NonceIPayload = PayloadHeader | NonceIData
>    ResponderIDPayload = PayloadHeader | RestOfIDPayload
>    RestOfRespIDPayload = IDType | RESERVED | InitIDData
>    MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
>
>
>
>Suggested:
>
>The responder's signed octets can be described as:
>
>    ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
>    GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
>    RealIKEHDR =  SPIi | SPIr |  . . . | Length
>    RealMessage2 = RealIKEHDR | RestOfMessage2
>    NonceIPayload = PayloadHeader | NonceIData
>    ResponderIDPayload = PayloadHeader | RestOfIDPayload
>    RestOfRespIDPayload = IDType | RESERVED | RespIDData
>    MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
>
>
>Comment:
>Changed "InitIDData" to "RespIDData". Unless I'm mistaken that "Init"
>stands for "Initiator", it should be "RespIDData". It's really a minor
>issue since RestofRespIDPayload infers the IDr Payload (and the
>Responder's Identification Data).
>
>
>- Jeff Sun
>_______________________________________________
>IPsec mailing list
>IPsec <at> ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 1 comment |
headers
Pasi.Eronen | 4 Apr 2008 13:21
Picon

Re: Bug: Section 2.15 - Responder Signed Octets

Looks correct to me.

Best regards,
Pasi 

> -----Original Message-----
> From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] 
> On Behalf Of ext Paul Hoffman
> Sent: 04 April, 2008 06:29
> To: Jeffrey Sun
> Cc: IPsec WG
> Subject: Re: [IPsec] Bug: Section 2.15 - Responder Signed Octets
> 
> I'm cleaning up some IKEv2bis issues, and noticed this one had not 
> been replied to. Does everyone agree that this change is correct?
> 
> --Paul Hoffman
> 
> At 2:17 PM -0800 3/6/08, Jeffrey Sun wrote:
> >Current:
> >
> >The responder's signed octets can be described as:
> >
> >    ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
> >    GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
> >    RealIKEHDR =  SPIi | SPIr |  . . . | Length
> >    RealMessage2 = RealIKEHDR | RestOfMessage2
> >    NonceIPayload = PayloadHeader | NonceIData
> >    ResponderIDPayload = PayloadHeader | RestOfIDPayload
> >    RestOfRespIDPayload = IDType | RESERVED | InitIDData
> >    MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
> >
> >
> >
> >Suggested:
> >
> >The responder's signed octets can be described as:
> >
> >    ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
> >    GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
> >    RealIKEHDR =  SPIi | SPIr |  . . . | Length
> >    RealMessage2 = RealIKEHDR | RestOfMessage2
> >    NonceIPayload = PayloadHeader | NonceIData
> >    ResponderIDPayload = PayloadHeader | RestOfIDPayload
> >    RestOfRespIDPayload = IDType | RESERVED | RespIDData
> >    MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
> >
> >
> >Comment:
> >Changed "InitIDData" to "RespIDData". Unless I'm mistaken that "Init"
> >stands for "Initiator", it should be "RespIDData". It's 
> really a minor
> >issue since RestofRespIDPayload infers the IDr Payload (and the
> >Responder's Identification Data).
> >
> >
> >- Jeff Sun
> >_______________________________________________
> >IPsec mailing list
> >IPsec <at> ietf.org
> >https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 4 Apr 2008 13:29
Picon

Re: Obsolete Statements in RFC4306 (IKEv2)

Chinh Nguyen wrote:

> Given this clarification in rfc 4718:
> <<
>     Moreover, the combination of ESP and AH (between the same
>     endpoints) had already become largely obsolete in 1998 when RFC
>     2406 was published.  Our recommendation is that IKEv2
>     implementations should not support this combination, and
>     implementers should not assume the combination can be made to
>     work in an interoperable manner.
>  >>
> 
> Are the following statements obsolete in rfc 4306:
> 
> <<
>     IKE can also negotiate use of IP Compression (IPComp) [IPCOMP]
>     in connection with an ESP and/or AH SA.
>  >>
> 
> should be "ESP or AH SA"

I agree; thanks for catching this! (Searching for the string "and/or"
reveals couple of other places that should be fixed in IKEv2bis.)

> <<
>     When SAs are nested, as when data (and IP headers if in tunnel
>     mode) are encapsulated first with IPComp, then with ESP, and
>     finally with AH between the same pair of endpoints, all of the
>     SAs MUST be deleted together.
>  >>
> 
> should be "first with IPComp, then with ESP or AH"

This has been fixed in the current IKEv2bis draft already.

> <<
>     If two successive structures have the same Proposal number, it
>     means that the proposal consists of the first structure AND the
>     second.  So a proposal of AH AND ESP would have two proposal
>     structures, one for AH and one for ESP and both would have
>     Proposal #1.
>  >>
> 
> (In fact, support for proposals with same number not necessary at
> all.  The only other usage I can think of, IPCOMP, is now a NOTIFY
> payload).

This has also been fixed already.

Best regards,
Pasi
Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 4 Apr 2008 13:36
Picon

Re: Fwd: I-D Action:draft-hoffman-ikev2bis-03.txt

(apologies for a late reply)

Jean-Michel Combes wrote:
> Hi,
> 
> I have two questions regarding this draft.
> 
> o Protocol ID field (section 3.10 - Protocol ID description)
> Is it normal the sentence "For IKE_SA notifications, this field MUST
> be one (1)" has been removed (in fact, this sentence has been removed
> since the version -01 of the draft)?

RFC 4718 Section 7.8 has some explanation about this situation.

Basically, RFC 4306 didn't actually say which notifications are about
IKE_SA (and thus it was unclear what implementations should send, or 
can expect to receive, in this field).

> o SPI field (section 3.10 - SPI Size description)
> It is said that "For a notification concerning the IKE_SA, the SPI
> Size MUST be zero.". Does it mean that the SPI MUST be empty too? Or
> is it just a way to identify this is a notification concerning the
> IKE_SA (and so the SPI field may be not empty) because, in this case,
> there is no more assigned value for the Protocol ID field?

If the SPI size is zero, the SPI field is also empty (otherwise, it
would be difficult to parse the message). For IKE_SA notifications,
the SPIs are in the message header, not inside the Notify payload.

Best regards,
Pasi
Permalink | Reply | 0 comments |
headers
Sean Lawless | 4 Apr 2008 22:54

Re: AH ICV calculation

Hi,

To conclude this thread, I tested our implementation with FreeBSD (Kame) 
today and found they interoperate just fine with static keys.  Thus the 
issue I encountered is Windows specific.  So if anyone else asks, the 
ipsec6.exe command on Windows cannot be used to configure static keys 
that inter operate with other IPSec implementations.  Maybe the next 
person who goes down this road will see this thread and avoid this.

Regards,
Sean

Sean Lawless wrote:
> Thanks Scott, your response was helpful.  I previously read this thread 
> on the web about Win2003 and Kame and then assumed that Windows was not 
> doing anything special and would interoperate:
>
> http://atm.tut.fi/list-archive/snap-users/msg03001.html
>
> It sounds like this may not be a safe assumption but I sure wish someone 
> at Microsoft would comment about this.  Has anyone successfully 
> interop'ed static keyed Window IPv6 
> (http://msdn2.microsoft.com/en-us/library/ms737602.aspx) with Kame or 
> another IPSec implementation?  If not my next step must be to test with 
> another implementation.
>
> Thanks for the help,
> Sean
>
>
> Scott C Moonen wrote:
>   
>> Hi Sean.  Please take the following with a grain of salt, because it 
>> is relayed secondhand, from a year or two ago, and the original tester 
>> is actually no longer with our company.  Our system test group was 
>> able to successfully implement dynamic SAs between our platform and 
>> Microsoft Windows.  One of our testers had some problems, however, 
>> configuring manual SAs between our platform and Windows.  We got the 
>> impression at the time that Windows doesn't directly use the key data 
>> that you enter in its configuration, but that it somehow hashes it to 
>> produce the actual key for the SA.  My recollection (could be wrong) 
>> is that he was able to enter key values longer than 16 bytes on 
>> Windows for various algorithms (both HMAC-x and encryption 
>> algorithms), and this may have been what led us to conclude that the 
>> key was derived from what he entered rather than being exactly what he 
>> entered.
>>
>> We couldn't find any documentation on how the keys are derived, and I 
>> don't know whether he pursued an answer from Microsoft support.  I 
>> suspect that he never got manual keys working.  It wasn't a high 
>> priority test in his case since we were able to successfully interact 
>> with numerous other platforms using manual SAs.  At very least, we 
>> don't currently have any manual SAs in our testbed between our 
>> platform and Windows (though we do have dynamic SAs).
>>
>> So you might consider trying your test with another platform than 
>> Windows; perhaps Linux or Cisco.  Alternatively, you might consider 
>> contacting Microsoft (or perhaps a Microsoft representative will 
>> comment in response to this) to understand how their implementation 
>> derives keys for manual SAs.  Lastly, you might consider dynamic SAs, 
>> though I realize that this may not be a trivial exercise. :)
>>
>> For what it's worth, with a quick seat-of-the-pants calculation I did 
>> arrive at the same ICV value for your sample data that you obtained. 
>>  That doesn't mean that you and I aren't making the same oversight. :)
>>
>>
>> Scott Moonen (smoonen <at> us.ibm.com)
>> z/OS Communications Server TCP/IP Development
>> http://scott.andstuff.org/
>> http://www.linkedin.com/in/smoonen
>>
>>
>> From: 	Sean Lawless <sean <at> blunkmicro.com>
>> To: 	ipsec <at> ietf.org
>> Date: 	04/02/2008 03:16 PM
>> Subject: 	[IPsec] AH ICV calculation
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Hi all,
>>
>> We are in the process of implementing static keyed IPSec for the IPv6
>> portion of a commercial TCP/IP stack and are having problems computing
>> the AH ICV correctly.  Using NULL as the authentication type there are
>> no problems communicating with other hosts (Windows XP) so I have ruled
>> out problems with packet decoding, SPI assignment, etc.  However, using
>> any HMAC algorithm (MD5-96 or SHA1-96) the calculated ICV never
>> matches.  I should also note that the HMAC algorithm we are using works
>> correctly with our TLS 1.0 implementation and so I feel we can rule out
>> HMAC and MD5/SHA1 algorithms as the problem.
>>
>> The ICV calculation matches if I test one Windows XP machine against
>> another or one of our development boards running our stack against
>> another.  This means our ICV calculation is consistent (but incorrect)
>> upon inbound and outbound processing.  I have read through the NetBSD
>> code (ah_core.c) and cannot find any difference in how they are muting
>> the IPv6 header fields vs. how we are...
>>
>> I have walked us through an example below that uses MD5 as the AH
>> algorithm with our implementation receiving an ICMPv6 ping from a
>> Windows XP host with outbound SPI 3001 (0x00000BB9), configured with
>> HMAC-MD5-96 and key file "0123456789ABCDEF":
>>
>> Complete ICMPv6 packet captured with Ethereal:
>>
>> 0000   00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00  ...T....`..>..`.
>> 0010   00 00 00 40 33 80 fe 80 00 00 00 00 00 00 02 1d  ... <at> 3...........
>> 0020   60 ff fe 0d 97 3e fe 80 00 00 00 00 00 00 02 00  `....>..........
>> 0030   00 ff fe 54 85 00 3a 04 00 00 00 00 0b b9 00 00  ...T..:.........
>> 0040   00 07 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a 80 00  ..1..?.m.X......
>> 0050   59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6a  Y3....abcdefghij
>> 0060   6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63  klmnopqrstuvwabc
>> 0070   64 65 66 67 68 69                                defghi
>>
>> Packet after mutable field hop limit and ICV are zero'd:
>>
>> 0000   00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00
>> 0010   00 00 00 40 33 00 FE 80 00 00 00 00 00 00 02 1D
>> 0020   60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 02 00
>> 0030   00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 00 00
>> 0040   00 07 00 00 00 00 00 00 00 00 00 00 00 00 80 00
>> 0050   59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6A
>> 0060   6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63
>> 0070   64 65 66 67 68 69
>>
>> The manual key being used is "0123456789ABCDEF" which has a key length
>> of 16.  After the HMAC init function is called with the key and key
>> length, the packet is processed with HMAC-MD5.  There are 104 bytes
>> processed from packet offset 000E to 0075:
>>
>> 60 00 00 00 00 40 33 00 FE 80 00 00 00 00 00 00
>> 02 1D 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00
>> 02 00 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9
>> 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00
>> 80 00 59 33 00 00 00 07 61 62 63 64 65 66 67 68
>> 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61
>> 62 63 64 65 66 67 68 69
>>
>> After the HMAC calculation is finished, the first 96 bits of the hash of
>> the above data is:
>>
>> 70 14 6d d1 15 4c 85 2c 26 a7 31 68
>>
>> Which does not match the ICV in the packet:
>>
>> 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a
>>
>> I have double checked and the HMAC-MD5-96 hash we calculated is correct
>> for the key and data being processed, therefore I can only assume that
>> the data we are processing is incorrect (or the manual key requires
>> preprocessing?).  I've reread the RFCs many times and am at a loss for
>> what could be the problem.  Can anyone spot what I am doing wrong?  Also
>> it would be very helpful to me if anyone could point to an example of AH
>> processing on an actual packet.  Something similar to the steps outlined
>> above?
>>
>> Best Regards,
>>
>> Sean Lawless
>> Blunk Microsystems LLC
>> _______________________________________________
>> IPsec mailing list
>> IPsec <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>   
>>     
> _______________________________________________
> IPsec mailing list
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
Permalink | Reply | 0 comments |
headers
Paul Hoffman | 7 Apr 2008 17:25

Fwd: [saag] TSVWG last call on "UDP Usage Guidelines for Application Designers" to BCP

[[ Of interest to us UDP-users. ]]

>Hi,
>
>I would like to inform that currently TSVWG has started the WG last call
>on "UDP Usage Guidelines for Application Designers"
>(draft-ietf-tsvwg-udp-guidelines-06) with the intended status of BCP. It
>runs until the 21st of April. If you like to provide any comments please
>send them to the TSVWG mailing list (tsvwg <at> ietf.org).
>
>Abstract:
>
>     The User Datagram Protocol (UDP) provides a minimal, message-passing
>     transport that has no inherent congestion control mechanisms.
>     Because congestion control is critical to the stable operation of the
>     Internet, applications and upper-layer protocols that choose to use
>     UDP as an Internet transport must employ mechanisms to prevent
>     congestion collapse and establish some degree of fairness with
>     concurrent traffic.  This document provides guidelines on the use of
>     UDP for the designers of such applications and upper-layer protocols.
>     Congestion control guidelines are a primary focus, but the document
>     also provides guidance on other topics, including message sizes,
>     reliability, checksums and middlebox traversal.
>
>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-06.txt
>
>Best Regards
>
>Magnus Westerlund
>
>IETF Transport Area Director & TSVWG Chair
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVM
>----------------------------------------------------------------------
>Ericsson AB                | Phone +46 8 4048287
>Färögatan 6                | Fax   +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
>----------------------------------------------------------------------

--Paul Hoffman, Director
--VPN Consortium
Permalink | Reply | 0 comments |

Gmane