[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: draft-ietf-ccamp-lmp
Did (rev 10 I suppose) get posted?
I do not see it!
Thanks,
Bert
> -----Original Message-----
> From: Jonathan Lang [mailto:Jonathan.Lang@rinconnetworks.com]
> Sent: dinsdag 30 september 2003 19:35
> To: Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert)
> Cc: Ccamp-wg (E-mail); Steve Bellovin (E-mail)
> Subject: RE: FW: draft-ietf-ccamp-lmp
>
>
> Dimitri, Bert, Steve,
> The LMP version on the IETF website isn't up-to-date with
> the Security
> Considerations changes because we were waiting for Steve's
> last comment
> on the selector issue. We ran the other changes by him back in August
> and I believe they were addressed to his satisfaction. I'll post the
> latest version of LMP tonight/tomorrow with his new comments in mind.
>
> Thanks,
> Jonathan
>
>
> > -----Original Message-----
> > From: Dimitri.Papadimitriou@alcatel.be
> > [mailto:Dimitri.Papadimitriou@alcatel.be]
> > Sent: Tuesday, September 30, 2003 4:18 AM
> > To: Wijnen, Bert (Bert)
> > Cc: Ccamp-wg (E-mail); Jonathan Lang; Steve Bellovin (E-mail)
> > Subject: Re: FW: draft-ietf-ccamp-lmp
> >
> >
> > bert, what we've addressed what was on the tracker webpage
> > i think this address what steve was referring here below
> > but now you're right that additional text migth be needed
> > if we further nail down flexibility, we'll come back with
> > structured text proposal - also i've rephrased one of the
> > comment made below - hope this will help jonathan -
> >
> > >>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
> > dynamic key exchange protocol using IKE."
> >
> > ---
> >
> > Wijnen, Bert (Bert) wrote:
> > > [ 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
> > >>
> > >>
> >
> > --
> > 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
> >
> >
>