Subject: [AAA-DOCTORS] REVIEW of draft-ietf-softwire-security-requirements-06.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 8 Feb 2009 15:17:58 +0200

Joe, could you please review this document for the AAA doctors team? 

I browsed through it and the term "AAA" was all over the place. 

Thanks. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
>Sent: 08 February, 2009 13:46
>To: [email-masked]; [email-masked]
>Subject: [AAA-DOCTORS] FW: 
>Evaluation:draft-ietf-softwire-security-requirements-06.txt to 
>ProposedStandard
>
> 
>
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-softwire-securit
>y-require
>ments-06.txt
>
>Technical Summary
>
>This document describes the security guidelines for the 
>softwire "Hubs and Spokes" and "Mesh" solutions. Together with 
>the discussion of the softwire deployment scenarios, the 
>vulnerability to the security attacks is analyzed to provide 
>the security protection mechanism such as authentication, 
>integrity and confidentiality to the softwire control and data packets.
>
>Working Group Summary
>
>The SOFTWIRE WG supports the development and advancement of 
>this document.
>
>Protocol Quality
>
>This document was thoroughly reviewed by WG chairs and WG 
>members, including those with expertise in security, IPv4 to 
>IPv6 transitions and interworking.
>
>RFC Editor Note
>
>  (Insert RFC Editor Note here or remove section)
>
>IRTF Note
>
>  (Insert IRTF Note here or remove section)
>
>IESG Note
>
>  (Insert IESG Note here or remove section)
>
>IANA Note
>
>  (Insert IANA Note here or remove section)
>
>
>
>
>
>
>_______________________________________________
>AAA-DOCTORS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/aaa-doctors
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 8 Feb 2009 21:04:38 -0800

OK, will do, it looks like this document is just entering IETF Last
Call, is that correct?  

Thanks,

Joe

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Sunday, February 08, 2009 5:18 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: REVIEW of draft-ietf-softwire-security-requirements-06.txt
> Importance: High
> 
>http://www.ietf.org/internet-drafts/draft-ietf-softwire-security-requir
ements-06.txt
> softwire "Hubs 
> >and Spokes" and "Mesh" solutions. Together with the 
> discussion of the 
> >softwire deployment scenarios, the vulnerability to the security 
> >attacks is analyzed to provide the security protection 
> mechanism such 
> >as authentication, integrity and confidentiality to the softwire 
> >control and data packets.
> >
> >Working Group Summary
> >
> >The SOFTWIRE WG supports the development and advancement of this 
> >document.
> >
> >Protocol Quality
> >
> >This document was thoroughly reviewed by WG chairs and WG members, 
> >including those with expertise in security, IPv4 to

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 16 Feb 2009 20:50:52 -0800

I've reviewed draft-ietf-softwire-security-requirements-06.txt as part
of the AAA doctors review process.  I found some issues that may need to
be addressed.  I focused mainly on the AAA issues within the document,
there may be other issues with the document not covered by this review. 

General comments: 

The document contains useful information, but I found it hard to follow.
This is partially because it has been a long time since I looked at L2TP
and softwires and partially because of the organization of the document.

The document does discuss AAA authentication with respect to several
deployment scenarios.  I found the document unclear as to how the AAA
integration was expected.  There are at least 4 different processes
mentioned that can integrate with AAA: PPP, L2TP, IKEv2 and L2/PANA
access authentication.  In most cases the document is not clear on what
is integrating with AAA.  Its not clear if AAA authentication needs to
be addressed at all these processes or what the relationship between
authentication at different process is.  Is a binding necessary between
the AAA authentication and an encrypted tunnel?   

Although trust relationships are identified the document does not define
the details what risks are assumed under the various models.  This
information helps to evaluate and manage the risk associated with the
trust relationship.

Below are some specific comments on the document:

1. section 3.2

This section describes a proxied trust model, but it does not provide
the details needed to evaluate and manage the risk associated with the
trust relationship.  For example it is state the visited AAA and home
AAA have a trust relationship: what does one rely upon the other to do?
What are the risks if the trust relationship is violated?  Are there
suggested ways to mitigate this risk?  

In section 3.2, the document makes the following statement:

"The SI and the visited AAA server do not usually have a trust
relationship;
however, if the SI can confirm that the home AAA server is involved
with the authentication of the SI and the visited AAA server does not
alter security information from the home AAA server, the visited AAA
server can be trusted by the SI."  

I'm not quite clear on what this sentence is stating.  There is no
direct connection made between this statement and mechanisms listed in
the document.  It does not appear that the SI can confirm the home AAA
server is involved using the mechanisms in the document or confirm that
the visited AAA server does not alter the security information (what is
security information).

This section also states:

" The communication between the SI, the home and visited AAA servers
must be protected. "

In general it doesn't appear that the SI and the home and visited AAA
servers communicate directly (I don't think the SI is a AAA client).
This needs to be clarified as to what process are involved in the
communication and what exactly needs to be protected. 

2. Section 3.4.1

Different authentication methods have different security properties.
For example, there are tremendous differences in security between PAP
and CHAP or between EAP-TLS and CHAP.  It seems there should be some
discussion of this.  I'm also a little bit surprised that mutual
authentication is only a SHOULD for the protocol (deployments may choose
not to enable it, but it seems the protocol should support it).  

3. Section 3.5

Its not clear to me how the tunnel is authenticated.  I think this
section needs to be clearer about the different authentication choices.
It covers several choices; pre-shared key, certificate, EAP, but doesn't
really describe where or how they should be used, or how they affect (or
don't affect) authentication in other processes.   Some of the drafts
(draft-eronen-ipsec-ikev2-eap-auth-05) mentioned in the section have
expired long ago.  

Joe

---

From: Shu Yamamoto <[email-masked]>
Date: Thu, 26 Feb 2009 12:34:54 +0900

Hello Joe;
We are updating document and will submit it shortly.
Prior to the submission, we would like to reply to your comments.
> authentication at different process is.
I hink that since L2TPv2 has different authentication processes such as 
PPP and L2TP authentications,
 it turns out to be difficult to follow. In addition, they are not 
sufficiently secured processes.
If L2TPv2 is used in unprotected network, the more secured 
authentication process such as IKE is required
as described in RFC3193.
In this document, we described IKEv2 with the authentication but not PANA.
We will add more text in Section 3.4.1 to clearly define the usage of 
PPP, L2TP and IKEv2
and AAA integration.
>   Is a binding necessary between
In some cases, it is not necessarily. But RFC4935 softwire problem 
statement states the softwire
solution must be able to be integrated with common deployed AAA solutions.
> information helps to evaluate and manage the risk associated with the
We will describe the risks in detail for three trust relationship 
scenarios indicated in Figure 1 of
the document.
> suggested ways to mitigate this risk?  
We will rewrite this section as the risks associated with the trust 
relationship are cleraly defined
for three specific acenarios. In terms of the trust relationship between 
the visted AAA and
the home AAA, the AAA proxy thret model will be addressed associated 
with the roaming agreement
between them.
> discussion of this.  
We will add the text on the security risks and discussion for these 
different authentications.
> I'm also a little bit surprised that mutual
Since the mutual authentication should be used in the specific cases, we 
will change the sentence
as you suggested.
> don't affect) authentication in other processes.   
We will add more text of where or how these three different 
authentication methods should be used.
> Some of the drafts
We will remove this draft as  a reference.

Regards,

Shu