[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt
From: "Vishwas Manral" <Vishwas () sinett ! com>
Date: 2005-01-31 17:24:51
Message-ID: BB6D74C75CC76A419B6D6FA7C38317B207EAB7 () sinett-sbs ! SiNett ! LAN
[Download RAW message or body]
--===============0682521258==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C507B9.C56C9920"
This is a multi-part message in MIME format.
Hi Tero,
Thanks a lot for the reply. My comments are prefixed with a "VM>"
> "All but the headers of all the messages that follow are encrypted and integrity \
> protected."
> Do we also mean to say that the header is integrity protected but
> not encrypted? We may want to clarify the text, and instead state
> "For all messages that folllow, the header is encrypted and the
> message including the header is integrity protected."
Header is not encrypted, the data after header is encrypted, so your
text is actually incorrect. It is true we could clarify that the
header is also integrity protected....
VM> I guess I agree the text I gave confused it further. What I meant is everything \
after the header is encrypted, and including the header is integrity protected. \
Maybe the text you state is clearer.
> 2. Section 3.3.2 - Transform type Values: -
>
> Encryption Algorithm (ENCR) 1 (IKE and ESP)
> Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP)
>
> I think we can remove the "optional" in ESP part for Integrity
> Algorithm. The optional part could be added instead to the
> Encryption Algorithm part.
No, we cannot remove that. Integrity is optional in ESP. Encryption is
NOT optional in the ESP. If you do not want to use encryption in ESP,
you need to negotiate cipher called ENCR_NULL.
VM> I think we can remove the "INTEG part is optional" in ESP part of it. If I see \
the Architecture document right, that is what is stated very clearly. Am I missing \
something there? This discrepancy seems to be in a lot of drafts.
> 6. In Section 2.13 we talk about (K, S) but never specify what K or
> S mean.
I think it is quite obvious that they are inputs to the function
prf+...
VM> Being a first time reader, I couldn't figure out what K and S stand for(inputs to \
the function for sure, what do they mean). It was not defined before or even in the \
same section(though everything else was).
> 8. We may want to state(obvious) that IKE message on port 4500,
> MUST have the first 4 bytes as zero on receipt and should always
> send the bytes as 0.
I think the section 3.1 says that:
----------------------------------------------------------------------
When sent on UDP port 4500, IKE messages have prepended four octets
of zero. These four octets of zero are not part of the IKE message
and are not included in any of the length fields or checksums
defined by IKE.
VM> I do not agree, it anywhere states that a value of non-zero on input is a wrong \
value. I think as a good protocol specification, we should clearly specify the \
behavior even in cases where an incorrect value is received(spcefying the values to \
receive). I know things may seem obvious to you but I guess to anyone implementing \
this, it may not. Though I have not worked on IKE for long enough, I have figured \
this out working and documenting other protocols.
Thanks,
Vishwas
________________________________
From: Tero Kivinen [mailto:kivinen@iki.fi]
Sent: Mon 1/31/2005 6:27 AM
To: Vishwas Manral
Cc: ipsec@ietf.org
Subject: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt
Vishwas Manral writes:
> 2. Section 3.3.2 - Transform type Values: -
>
> Encryption Algorithm (ENCR) 1 (IKE and ESP)
> Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP)
>
> I think we can remove the "optional" in ESP part for Integrity
> Algorithm. The optional part could be added instead to the
> Encryption Algorithm part.
No, we cannot remove that. Integrity is optional in ESP. Encryption is
NOT optional in the ESP. If you do not want to use encryption in ESP,
you need to negotiate cipher called ENCR_NULL.
> 4. Section 1.2 states: -
>
> "All but the headers of all the messages that follow are encrypted and integrity \
> protected."
> Do we also mean to say that the header is integrity protected but
> not encrypted? We may want to clarify the text, and instead state
> "For all messages that folllow, the header is encrypted and the
> message including the header is integrity protected."
Header is not encrypted, the data after header is encrypted, so your
text is actually incorrect. It is true we could clarify that the
header is also integrity protected....
> 6. In Section 2.13 we talk about (K, S) but never specify what K or
> S mean.
I think it is quite obvious that they are inputs to the function
prf+...
> 8. We may want to state(obvious) that IKE message on port 4500,
> MUST have the first 4 bytes as zero on receipt and should always
> send the bytes as 0.
I think the section 3.1 says that:
----------------------------------------------------------------------
When sent on UDP port 4500, IKE messages have prepended four octets
of zero. These four octets of zero are not part of the IKE message
and are not included in any of the length fields or checksums
defined by IKE.
--
kivinen@safenet-inc.com
[Attachment #3 (text/html)]
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.6944.0">
<TITLE>[Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText17559 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Hi Tero,</FONT></DIV></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Thanks a lot for the reply. My comments are prefixed with a
"VM>"</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><FONT size=2>> "All but the headers of all the messages that
follow are encrypted and integrity protected."<BR>><BR>> Do we also mean
to say that the header is integrity protected but<BR>> not encrypted? We may
want to clarify the text, and instead state<BR>> "For all messages that
folllow, the header is encrypted and the<BR>> message including the header is
integrity protected."<BR><BR>Header is not encrypted, the data after header is
encrypted, so your<BR>text is actually incorrect. It is true we could clarify
that the<BR>header is also integrity protected....</FONT></DIV>
<DIV dir=ltr><FONT size=2>VM> I guess I agree the text I gave confused it
further. What I meant is everything after the</FONT><FONT size=2> header is
encrypted, and including the header is integrity protected. Maybe the text
you state is clearer.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>> 2. Section 3.3.2 - Transform type Values:
-<BR>><BR>> Encryption Algorithm (ENCR) 1
(IKE and ESP)<BR>> Integrity Algorithm (INTEG)
3 (IKE, AH, optional in ESP)<BR>><BR>> I think we can remove the
"optional" in ESP part for Integrity<BR>> Algorithm. The optional part could
be added instead to the<BR>> Encryption Algorithm part.<BR><BR>No, we cannot
remove that. Integrity is optional in ESP. Encryption is<BR>NOT optional in the
ESP. If you do not want to use encryption in ESP,<BR>you need to negotiate
cipher called ENCR_NULL.</FONT><BR>VM> I think we can remove the "INTEG part
is optional" in ESP part of it. If I see the Architecture document right, that
is what is stated very clearly. Am I missing something there? This
discrepancy seems to be in a lot of drafts. <BR></DIV>
<DIV dir=ltr><FONT size=2>> 6. In Section 2.13 we talk about (K, S) but
never specify what K or<BR>> S mean.<BR>I think it is
quite obvious that they are inputs to the function<BR>prf+...</FONT><BR>VM>
Being a first time reader, I couldn't figure out what K and S stand for(inputs
to the function for sure, what do they mean). It was not defined before or even
in the same section(though everything else was).</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><FONT size=2>> 8. We may want to state(obvious) that IKE
message on port 4500,<BR>> MUST have the first 4
bytes as zero on receipt and should always<BR>> send
the bytes as 0.<BR>I think the section 3.1 says
that:<BR>----------------------------------------------------------------------<BR>
When sent on UDP port 4500, IKE messages have prepended four
octets<BR> of zero. These four octets of zero are not part of the
IKE message<BR> and are not included in any of the length fields or
checksums<BR> defined by IKE.</FONT><BR>VM> I do not agree, it
anywhere states that a value of non-zero on input is a wrong value. I
think as a good protocol specification, we should clearly specify the behavior
even in cases where an incorrect value is received(spcefying
the values to receive). I know things may seem obvious to you but I guess
to anyone implementing this, it may not. Though I have not worked on IKE for
long enough, I have figured this out working and documenting other
protocols.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Thanks,</DIV>
<DIV dir=ltr>Vishwas</DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> Tero Kivinen
[mailto:kivinen@iki.fi]<BR><B>Sent:</B> Mon 1/31/2005 6:27 AM<BR><B>To:</B>
Vishwas Manral<BR><B>Cc:</B> ipsec@ietf.org<BR><B>Subject:</B> [Ipsec] Comments:
draft-ietf-ipsec-ikev2-17.txt<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Vishwas Manral writes:<BR>> 2. Section 3.3.2 - Transform type
Values: -<BR>><BR>> Encryption Algorithm (ENCR)
1 (IKE and ESP)<BR>> Integrity Algorithm
(INTEG) 3 (IKE, AH, optional in
ESP)<BR>><BR>> I think we can remove the "optional" in ESP part for
Integrity<BR>> Algorithm. The optional part could be added instead to
the<BR>> Encryption Algorithm part.<BR><BR>No, we cannot remove that.
Integrity is optional in ESP. Encryption is<BR>NOT optional in the ESP. If you
do not want to use encryption in ESP,<BR>you need to negotiate cipher called
ENCR_NULL.<BR><BR>> 4. Section 1.2 states: -<BR>><BR>> "All but the
headers of all the messages that follow are encrypted and integrity
protected."<BR>><BR>> Do we also mean to say that the header is integrity
protected but<BR>> not encrypted? We may want to clarify the text, and
instead state<BR>> "For all messages that folllow, the header is encrypted
and the<BR>> message including the header is integrity
protected."<BR><BR>Header is not encrypted, the data after header is encrypted,
so your<BR>text is actually incorrect. It is true we could clarify that
the<BR>header is also integrity protected....<BR><BR>> 6. In Section
2.13 we talk about (K, S) but never specify what K
or<BR>> S mean.<BR><BR>I think it is quite obvious
that they are inputs to the function<BR>prf+...<BR><BR>> 8. We may want
to state(obvious) that IKE message on port 4500,<BR>>
MUST have the first 4 bytes as zero on receipt and should
always<BR>> send the bytes as 0.<BR><BR>I think the
section 3.1 says
that:<BR><BR>----------------------------------------------------------------------<BR>
When sent on UDP port 4500, IKE messages have prepended four
octets<BR> of zero. These four octets of zero are not part of the
IKE message<BR> and are not included in any of the length fields or
checksums<BR> defined by
IKE.<BR>--<BR>kivinen@safenet-inc.com<BR></FONT></P></DIV>
</BODY>
</HTML>
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
--===============0682521258==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic