[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>
>