-Original Message-
From: btns-boun...@ietf.org [mailto:btns-boun...@ietf.org] On Behalf Of
rfc-edi...@rfc-editor.org
Sent: Wednesday, October 28, 2009 21:19
To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org
Cc: b...@ietf.org; rfc-edi...@rfc-editor.org
Subject: [btns] RFC 5660 on IPsec
Tero and Sheila,
> The AUTH_HMAC_MD5_128 and
> AUTH_HMAC_SHA1_160 are really only specified when used with Fibre
> Channel CT_Authentication format instead of ESP format. Even when
> using fibre channel if ESP format is used then I think you must use
> the truncated versions.
That is correct for
Here is the proposed agenda for our meeting in Hiroshima in two weeks. Let us
know if you have any concerns about it.
IPsecME WG
2009-11-12, Thursday, 0900-1130
0900 Agenda bash and start blue sheets and RFID scanning
0905 Brief review of document status
0915 Review of proposed new work items
Frankel, Sheila E. writes:
>
> #115: Camellia req levels for IKEv2
>
> Proposed changes to Roadmap doc:
>
> 1) Change IKEv2 requirement level for Camellia-CBC from undefined (no RFC)
> to optional
>
> 2) Add text to Section 5.2.6 (RFC 4312, The Camellia Cipher Algorithm and Its
Frankel, Sheila E. writes:
> 2) Add text to the introductory section for IKEv1, Section 4.1.1:
>
> Additional text:
...
> Two Internet Drafts were written to address these problems: Extended
> Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth) and The
^
within
> ISAK
Frankel, Sheila E. writes:
>
> #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?
>
> Proposed changes to Roadmap doc:
>
> 1) Add text to section 5.4 (Combined Mode Algorithms)
...
> Additional text:
>Some IKEv1 implementations have added the capability to negotiate
>
Frankel, Sheila E. writes:
> Additional text:
>Some of these algorithms generate a fixed-length ICV, which is truncated
>when it is included in an IPsec-protected packet. For example, standard
>HMAC-SHA-1 generates a 160-bit ICV, which is truncated to 96 bits when it
>is used to
