[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: draft-ietf-ccamp-lmp
[ I have cc:-ed the ccamp WG list again, we MUST keep the WG
involved in this. Or at least allow any WG memebr to jump in
if they have opinions or contributions]
Thanks Dimitri.
I am not sure though that you have answered:
> 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.
Can you rty to compose an answer to that.
Possibly some text to address these questions needs to go in the
document itself as well.
Thanks,
Bert
> -----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
>
>