[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ipsec] Some (hopefully final) comments to thedraft-ietf-ipsec-ikev2-15.txt
Tero:
The IKEv2 document is on the IESG Telechat agenda for this coming
Thursday. I put it there because at least one of the ADs has not told us
whether the update resolved their DISCUSS comments. I am forcing the
issue. If another version is needed to resolve this comment, then the
changes can be made at the same time. Otherwise, I think a RFC Editor not
is appropriate,
Russ
Tero Kivinen wrote:
>I just finished reading the draft-ietf-ipsec-ikev2-15.txt completely
>again. I found some small points, which probably can either be left as
>they are or fixed during the authors 48 hours notice...
>
>Perhaps the area directors can confirm whether we can fix those in
>last edit phase, if not, then I think we can just leave the changes
>out (the only real issue is the issue number 3 below, as it will
>affect interoperability).
>
>----------------------------------------------------------------------
>
>1) Section 3.6 Certificate Payload refers X.509 certificates and CLRs
> as a BER encoded x.509 certificate / CRL. I think it should use DER
> instead of BER. Of course DER is a subset of BER, so all DER
> encoded objects are also BER encoded, but not other way around, and
> the certificates etc must always DER encoding, as it must be same
> regardless who encoded it.
>
> I have seen some LDAP servers who took DER encoded certificate, and
> re-encoded it using BER when sending it out, and that of course
> caused the signatures to fail etc.
>
>so change
>
> X.509 Certificate - Signature (4) contains a BER encoded X.509
> certificate whose public key is used to validate the sender's AUTH
> payload.
>
> Certificate Revocation List (7) contains a BER encoded X.509
> certificate revocation list.
>
>to
>
> X.509 Certificate - Signature (4) contains a DER encoded X.509
> certificate whose public key is used to validate the sender's AUTH
> payload.
>
> Certificate Revocation List (7) contains a DER encoded X.509
> certificate revocation list.
>
>
>and
>
> Hash and URL encodings (12-13) allow IKE messages to remain short
> by replacing long data structures with a 20 octet SHA-1 hash of
> the replaced value followed by a variable length URL that resolves
> to the BER encoded data structure itself. ...
>
>to
>
> Hash and URL encodings (12-13) allow IKE messages to remain short
> by replacing long data structures with a 20 octet SHA-1 hash of
> the replaced value followed by a variable length URL that resolves
> to the DER encoded data structure itself. ...
>
>----------------------------------------------------------------------
>
>2) Section 3.7 Certificate Request Payload refers still in one place
> to CA name instead of the hash of the CA public key.
>
>so change
>
> means. Thus the processing of a CERTREQ CA name should be seen as a
> suggestion for a certificate to select, not a mandated one. If no
> certificates exist then the CERTREQ is ignored. This is not an error
>
>to
>
> means. Thus the processing of a CERTREQ should be seen as a
> suggestion for a certificate to select, not a mandated one. If no
> certificates exist then the CERTREQ is ignored. This is not an error
>
>There is also extra " at the end of that paragraph, which can be
>removed at the same time...
>
>----------------------------------------------------------------------
>
>3) Section 3.15.1 Configuration Attributes has a table listing which
> of the attributes are multivalued and which are not. The
> INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET are listed in the table
> as NO (i.e. not multivalued), but the describing text later says
> "The responder MAY respond with zero or more sub-network
> attributes.", which indicates that they should be multivalued.
>
> As it do make sense to send multiple subnets, I think the text is
> correct and the table is incorrect.
>
>so change:
>
> INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets
> SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
> INTERNAL_IP6_SUBNET 15 NO 17 octets
>
>to
>
> INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
> SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
> INTERNAL_IP6_SUBNET 15 YES 17 octets
>
>----------------------------------------------------------------------
>
>4) RFC2401bis reference should have the draft name, as it would make
> rfc-editors life easier when finding the correct reference, and
> fixing it to match the rfc number.
>
>so change:
>
> [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture
> for the Internet Protocol", un-issued Internet
> Draft, work in progress.
>
>to
>
> [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture
> for the Internet Protocol", draft-ietf-ipsec-
> rfc2401bis-02.txt, April 2004, work in progress.
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec