The document does not spell out the foundation for trust, and this
makes it difficult to understand what problem is being solved. Why
does one need authentication of the IP address? Why would one use
identity protection in this scenario? And why not simply use one IKE
pathway as a MUST and be done with it (e.g. aggressive mode digital
signature)? IKE's flexibility is there to support various usage
scenarios, and this seems like an ideal situation to say, "we know the
scenario and we don't need flexibility." Nail it down.
-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: dinsdag 30 september 2003 12:33
To: Wijnen, Bert (Bert)
Cc: Jonathan Lang; Steve Bellovin (E-mail)
Subject: Re: FW: draft-ietf-ccamp-lmp
hi bert, to address these i would propose the following (i've
work this out with o.paridaens) - note we did this some time
ago and propose this in order to move this forward, jonathan
is free to take these into consideration or leave them:
1. > SMB:
> Most of my comments have not been addressed. I said the
following
> about 16.2:
>
> The IPsec selectors are all SHOULDs -- what are the MUSTs?
> Setting the port number to 0 means that all UDP
traffic between
> those nodes is protected -- is that right? I though the
> document spoke of an LMP port.
Section 16.2:
- "2. IKE [RFC2409] SHOULD be used as the key exchange mechanism."
to be replaced by:
- "2. IKE [RFC2409] MUST be used as the key exchange mechanism."
2. > Point 2 still has SHOULD instead of MUST, and still
says UDP port 0.
note: i don't know about steve's views here but it seems to accept
the previous version of it
Section 16.2:
- "The identities SHOULD be of type IP addresses
and the value of the identities SHOULD be the IP addresses of the
communicating peers. The protocol field SHOULD be IP protocol UDP
(17). The port field SHOULD be set to zero to indicate
port fields
should be ignored."
to be replaced by:
- "The identities MUST be of type IP addresses
and the value of the identities MUST be the IP addresses of the
communicating peers. The protocol field MUST be IP protocol UDP
(17). The port field SHOULD be set to the LMP UDP port
as assigned
by IANA."
> The channel identifer is part of the payload, not
the IP or UDP
> headers, and thus can't be a selector.
>
> There is still text about the channel identifier, in a
context that
> makes it appear like part of the selector.
3. Section 16.2:
- "In LMP exchanges, the channel identifier user by the peer is not
known beforehand, and hence cannot be used in the SA."
is suggested to be to be removed.
4.
> IKE is listed as a SHOULD, not a MUST, but the requirements
> mandate replay detection. You can't do that with
manual keying.
> (The requirements also mandate support for manual keying.)
> If replay protection is needed, either IKE must be required,
> or an application-specific replay protection mechanism must
> be defined.
>
> 16.1 now speaks of automatic key management, but it says
"should" (not
> SHOULD), when it needs to say MUST, and point 2 of 16.2
still mandates
> manual keying. That has to be deleted.
Section 16.1:
- "Security mechanism should provide for well defined key
management schemes."
to be replaced by:
- "Security mechanism MUST provide for well defined key
management schemes."
and
Section 16.2:
- "Implementations of LMP over IPsec protocol MUST support manual
keying mode and dynamic key exchange protocol using IKE."
to be replaced by:
- "Implementations of LMP over IPsec protocol MUST support manual
dynamic key exchange protocol using IKE."
5. IPSEC Tunnels
> All LMP messages are expected to be sent over the
IPsec tunnel.
> However, all LMP messages should be sent through the
IPsec tunnel,
> which will have been established earlier or on an
as-needed basis.
proposal to rephrase but might need to be discussed in case of
change of semantic:
"All LMP messages should be sent through the IPsec tunnel, which
will have been established earlier or on an as-needed basis."
---
Wijnen, Bert (Bert) wrote:
I think it is important that the whole ccamp list sees this.
If there are people who want to help Jonathan formulating an
answer and possible updates to the draft, please do so!
Thanks,
Bert
-----Original Message-----
From: Steven M. Bellovin [mailto:smb@research.att.com]
Sent: maandag 29 september 2003 20:26
To: Wijnen, Bert (Bert)
Cc: 'Jonathan Lang'
Subject: Re: draft-ietf-ccamp-lmp
In message
<7D5D48D2CAA3D84C813F5B154F43B15502331618@nl0006exch001u.nl.lucent.c
om>, "Wijnen, Bert (Bert)" writes:
Steve, to be fair to Jonathan and the WG, I do think that
this is taking too long now. PLEASE ?
Sorry, I'd meant to send you this on Friday.
I've been unable to get much input from the security
directorate on my
main complaint, but that's a problem I'll have to deal
with. I did get
a few comparatively minor issues, which I'll write up and
forward to
you in the next day or two. They'll likely require a new I-D to
clarify a few points, but (I believe) nothing substantive;
it's just
that there are too many to make an RFC Editor's note practical.
Steve, pls make sure your comment are against the latest revision,
draft-ietf-ccamp-lmp-09.txt
After checking the comments I received against the latest
version, I'm
more confused than ever, since some of them don't seem to
apply to any
version of the document... That said, there are two
comments that do
seem to apply:
The document does not spell out the foundation for
trust, and this
makes it difficult to understand what problem is being
solved. Why
does one need authentication of the IP address? Why
would one use
identity protection in this scenario? And why not
simply use one IKE
pathway as a MUST and be done with it (e.g. aggressive
mode digital
signature)? IKE's flexibility is there to support various usage
scenarios, and this seems like an ideal situation to
say, "we know the
scenario and we don't need flexibility." Nail it down.
and
I admit the following completely defeats me:
All LMP messages are expected to be sent over the
IPsec tunnel.
However, all LMP messages should be sent through the
IPsec tunnel,
which will have been established earlier or on an
as-needed basis.
"over" vs. "through"? "However" as opposed to what?
I'm still unhappy about using port number zero, but I'll
let that pass.
--Steve Bellovin, http://www.research.att.com/~smb
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491