Comments on draft-ietf-softwire-security-requirements-02

Hi,

I just read the draft and I had some comments as follows:

> 1.  Introduction
>    Layer Two Tunneling Protocol (L2TPv2) selected for
"Hubs and Spokes"
>    solution MUST use IPsec if the secure communication
is
>    required[RFC3193].  This document provides the
implementation
>    guidance (and proper usage) of IPsec as the security
protection
>    mechanism by considering the various security
vulnerabilities in
>    "Hubs and Spokes" scenarios.  IKEv2 SHOULD
be used in the key
>    management protocol for IPsec as the reason of the
future proven
>    technology as opposed to IKEv1.

I think it's less important to secure the communication 
of the devices which have direct access to its home carrier
network. therefore I think it's better to clarify that
securing the communication for normadic access scenario
is important by modifying first sentence. e.g.

'For normadic access scenario of "Hubs and Spokes"
solution,
using IPsec as described in [RFC3193] is applicable and
strongly
desired and recommenced to secure the communication.'

> 3.1.  Deployment Scenarios
>    However, the host device may not always have direct
access to its
>    home carrier network, to which the user has
subscribed.  For example,
>    the softwire initiator in the laptop PC can access
various access
>    networks such as Wi-Fi hot-spots, visited office
network.  This is
>    the nomadic case, which the Softwire SHOULD
support.

ditto, I think it's better to add the words for
clarification.
e.g. 'in this normadic case, using IPsec is strongly
desired
and recommended. therefore, IPsec implementation SHOULD be
suppored by the softwire.'

> 3.4.1.1.  PPP Authentication
> 
>    PPP can provide mutual authentication between the SI
and SC using
>    CHAP [RFC1994] during the connection establishment
phase (Link
>    Control Protocol, LCP).  PPP CHAP authentication can
be used when the
>    SI and SC are on a trusted, non-public IP network.
> 
>    Since CHAP does not provide per-packet
authentication, integrity, or
>    replay protection, PPP CHAP authentication MUST NOT
be used
>    unprotected on a public IP network.

I think here is a gap in the logic. PPP CHAP and other
mechanism
(IPsec) could be co-existent. so there seems to be no
reason
to eliminate PPP CHAP.

> 3.4.1.1.1.  L2TPv2 Authentication
> 
>    L2TPv2 provides an optional CHAP-like[RFC1994]
tunnel authentication
>    during the control connection establishment
[RFC2661, 5.1.1].  The
>    same restrictions apply to L2TPv2 authentication and
PPP CHAP.

ditto.

thanks,

--
Yasuhiro SHIRASAKI  NTT Communications
t: +81-3-6800-3262, f: +81-3-5365-2990

_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires

Hello Yasuhiro.

Thanks for taking time to comment the draft. My comments
inline.

--On 19 mars 2007 18:57:23 +0900 Yasuhiro SHIRASAKI
<yasuhironttv6.jp> 
wrote:

> Hi,
>
> I just read the draft and I had some comments as
follows:
>
>> 1.  Introduction
>>    Layer Two Tunneling Protocol (L2TPv2) selected
for "Hubs and Spokes"
>>    solution MUST use IPsec if the secure
communication is
>>    required[RFC3193].  This document provides the
implementation
>>    guidance (and proper usage) of IPsec as the
security protection
>>    mechanism by considering the various security
vulnerabilities in
>>    "Hubs and Spokes" scenarios.  IKEv2
SHOULD be used in the key
>>    management protocol for IPsec as the reason of
the future proven
>>    technology as opposed to IKEv1.
>
> I think it's less important to secure the
communication
> of the devices which have direct access to its home
carrier
> network. therefore I think it's better to clarify that
> securing the communication for normadic access
scenario
> is important by modifying first sentence. e.g.
>
> 'For normadic access scenario of "Hubs and
Spokes" solution,
> using IPsec as described in [RFC3193] is applicable and
strongly
> desired and recommenced to secure the communication.'

This document does not want to mandate IPsec in *all* cases.
We tried to 
identify scenarios where security is required, and what
security to apply 
(IPsec). We'll change some text in the introduction to
clarify this.

The security analysis in RFC 3193 is quite appropriate for
this draft. This 
draft will describe how recommendations from RFC 3193 can be
applied using 
the new IPsec security architecture (RFC4301) and IKEv2.

>
>> 3.1.  Deployment Scenarios
>>    However, the host device may not always have
direct access to its
>>    home carrier network, to which the user has
subscribed.  For example,
>>    the softwire initiator in the laptop PC can
access various access
>>    networks such as Wi-Fi hot-spots, visited office
network.  This is
>>    the nomadic case, which the Softwire SHOULD
support.
>
> ditto, I think it's better to add the words for
clarification.
> e.g. 'in this normadic case, using IPsec is strongly
desired
> and recommended. therefore, IPsec implementation SHOULD
be
> suppored by the softwire.'

The reason IPsec is not mentioned here is that we haven't
yet discussed 
what are the security requirements (defined in 3.4). We're
just stating a 
"use case" for softwire.

>
>> 3.4.1.1.  PPP Authentication
>>
>>    PPP can provide mutual authentication between
the SI and SC using
>>    CHAP [RFC1994] during the connection
establishment phase (Link
>>    Control Protocol, LCP).  PPP CHAP authentication
can be used when the
>>    SI and SC are on a trusted, non-public IP
network.
>>
>>    Since CHAP does not provide per-packet
authentication, integrity, or
>>    replay protection, PPP CHAP authentication MUST
NOT be used
>>    unprotected on a public IP network.
>
> I think here is a gap in the logic. PPP CHAP and other
mechanism
> (IPsec) could be co-existent. so there seems to be no
reason
> to eliminate PPP CHAP.

I agree that we should not eliminate CHAP, and we are not.
The key word 
here is "unprotected". If you're L2TP tunnel is
protected using IPsec, 
nothing here prohibits using CHAP user authentication.

>
>> 3.4.1.1.1.  L2TPv2 Authentication
>>
>>    L2TPv2 provides an optional CHAP-like[RFC1994]
tunnel authentication
>>    during the control connection establishment
[RFC2661, 5.1.1].  The
>>    same restrictions apply to L2TPv2 authentication
and PPP CHAP.
>
> ditto.

Ditto 

We'll add some text to clarify that L2TPv2 should not be
used unprotected, 
as for CHAP. Sounds ok?

Thanks again.
Florent




_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires

Hi Florent,

On Wed, 21 Mar 2007 14:29:09 +0100,
Florent Parent <Florent.Parentbeon.ca> wrote:
> 
> Hello Yasuhiro.
> 
> Thanks for taking time to comment the draft. My
comments inline.
> 
> --On 19 mars 2007 18:57:23 +0900 Yasuhiro SHIRASAKI
<yasuhironttv6.jp> 
> wrote:
> 
> > Hi,
> >
> > I just read the draft and I had some comments as
follows:
> >
> >> 1.  Introduction
> >>    Layer Two Tunneling Protocol (L2TPv2)
selected for "Hubs and Spokes"
> >>    solution MUST use IPsec if the secure
communication is
> >>    required[RFC3193].  This document provides
the implementation
> >>    guidance (and proper usage) of IPsec as the
security protection
> >>    mechanism by considering the various
security vulnerabilities in
> >>    "Hubs and Spokes" scenarios. 
IKEv2 SHOULD be used in the key
> >>    management protocol for IPsec as the reason
of the future proven
> >>    technology as opposed to IKEv1.
> >
> > I think it's less important to secure the
communication
> > of the devices which have direct access to its
home carrier
> > network. therefore I think it's better to clarify
that
> > securing the communication for normadic access
scenario
> > is important by modifying first sentence. e.g.
> >
> > 'For normadic access scenario of "Hubs and
Spokes" solution,
> > using IPsec as described in [RFC3193] is
applicable and strongly
> > desired and recommenced to secure the
communication.'
> 
> This document does not want to mandate IPsec in *all*
cases. We tried to 
> identify scenarios where security is required, and what
security to apply 
> (IPsec). We'll change some text in the introduction to
clarify this.
> 
> The security analysis in RFC 3193 is quite appropriate
for this draft. This 
> draft will describe how recommendations from RFC 3193
can be applied using 
> the new IPsec security architecture (RFC4301) and
IKEv2.

When I read the draft, I was afraid that IPsec would be
mandated.
That's the reason why I sent my comments. I believe the
clarification
helps a lot.

> >> 3.1.  Deployment Scenarios
> >>    However, the host device may not always
have direct access to its
> >>    home carrier network, to which the user has
subscribed.  For example,
> >>    the softwire initiator in the laptop PC can
access various access
> >>    networks such as Wi-Fi hot-spots, visited
office network.  This is
> >>    the nomadic case, which the Softwire SHOULD
support.
> >
> > ditto, I think it's better to add the words for
clarification.
> > e.g. 'in this normadic case, using IPsec is
strongly desired
> > and recommended. therefore, IPsec implementation
SHOULD be
> > suppored by the softwire.'
> 
> The reason IPsec is not mentioned here is that we
haven't yet discussed 
> what are the security requirements (defined in 3.4).
We're just stating a 
> "use case" for softwire.

agree.

> >> 3.4.1.1.  PPP Authentication
> >>
> >>    PPP can provide mutual authentication
between the SI and SC using
> >>    CHAP [RFC1994] during the connection
establishment phase (Link
> >>    Control Protocol, LCP).  PPP CHAP
authentication can be used when the
> >>    SI and SC are on a trusted, non-public IP
network.
> >>
> >>    Since CHAP does not provide per-packet
authentication, integrity, or
> >>    replay protection, PPP CHAP authentication
MUST NOT be used
> >>    unprotected on a public IP network.
> >
> > I think here is a gap in the logic. PPP CHAP and
other mechanism
> > (IPsec) could be co-existent. so there seems to be
no reason
> > to eliminate PPP CHAP.
> 
> I agree that we should not eliminate CHAP, and we are
not. The key word 
> here is "unprotected". If you're L2TP tunnel
is protected using IPsec, 
> nothing here prohibits using CHAP user authentication.

I got your point.

> >> 3.4.1.1.1.  L2TPv2 Authentication
> >>
> >>    L2TPv2 provides an optional
CHAP-like[RFC1994] tunnel authentication
> >>    during the control connection establishment
[RFC2661, 5.1.1].  The
> >>    same restrictions apply to L2TPv2
authentication and PPP CHAP.
> >
> > ditto.
> 
> Ditto 
> 
> We'll add some text to clarify that L2TPv2 should not
be used unprotected, 
> as for CHAP. Sounds ok?

sounds nice.

thanks.

--
Yasuhiro SHIRASAKI  NTT Communications
t: +81-3-6800-3262, f: +81-3-5365-2990

_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires