[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: On revised identity (was "Moving forward...final edits...)




I have different view on this.  The purpose of revised identity draft is to
address the issues when using certificate.  However, I think most of the
confuse comes from lack of clarification on how to deal with identity
payload (similar to what draft-ietf-ipsec-pki-profile-01.txt does).  Replace
it with new set of identity won't get any better without clear and detailed
clarification of the usages.

my comments on FullID payload:
1. For type 1 (standalone certificate), why it's better than ID_DER_ASN1_DN?

2. FOR type 3 (hash and URL), is it dangerous that the gateway will try to
do http with innocent party with instruction of unauthenticated peer?

3. For type 6 (IDForShareSecret), if both sides know the ip address of the
peer and try to convert their ip address into ascii string, they may have
different translation (eg. "::3:1" vs "00::03:01" in IPv6).  

=======================
Michael Shieh


-----Original Message-----
From: Gregory Lebovitz [mailto:Gregory@netscreen.com]
Sent: Thursday, February 06, 2003 11:03 AM
To: 'Derrell Piper'; Theodore Ts'o; ipsec@lists.tislabs.com
Subject: RE: On revised identity (was "Moving forward...final edits...)


Derrell, thanks for taking the lead to summarize this for us.

Comments on your summary within...

> -----Original Message-----
> From: Derrell Piper [mailto:ddp@electric-loft.org]
> Sent: Wednesday, February 05, 2003 3:46 PM
> To: Theodore Ts'o
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Moving forward with IKE V2: A proposal for final edits to
> ikev2-04
--SNIP-- 
> 
> Would the proposed identity revisions make things so much better that 
> it would clear up some large majority of PKI interoperability 
> problems? 

It would make the IDforSharedSecret completely straightforward, which
addresses 90%+ of the deployments going out.

For those very few deployments that use certs, it makes using certs more
efficient (don't have to send the cert every IKE exchange). It also removes
the issue of how to configure and what to configure in the various cert
fields a non-issue for the protocol. The user can specify whatever they want
wherever they want in the cert, and as long as the implementation allows
them to, via UI, select and match those fields' contents, it will work.

>   I don't think so.  I think most of the problems are due somewhat to 
> the inherent complexity of certificate-based PKI 
> interoperability and, 
> moreover, to the lack of a defined PKI profile for IKE.  I happen to 
> think there's more value in defining a PKI profile, such as the one 
> described in, draft-ietf-ipsec-pki-profile-01.txt.  We don't need 
> revised identities to do that.  It seems similarly clear that revised 
> identities would bring with them a new and entirely different set of 
> interoperability issues.

Regardless of revised identities, we definitely need a cert profile, but the
total amount of things we need to specify in the cert profile for v2 will be
much less than the equivalent document for v1.


> I have concerns that the management paradigm for many vendors is very 
> closely tied to the existing IKE identity types, so wholesale 
> revision 
> in this area might well represent a serious headache for many 
> vendors.  
> The impact of the protocol changes is largely transparent and 
> the other 
> revisions ought to mostly present themselves as elimination of 
> unnecessary configuration options.  Deleting things is 
> relative easy.  
> But I can see how wholesale identity revision might seriously impact 
> much of the existing management software, end-user documentation, and 
> vendor regression testing.  I think we do need to be concerned about 
> fielded implementations.

This is a great point. Must of us have already developed extensive and
complicated management stuff to get around the perplexity of the v1 protocol
wrt identity and certs. I agree, we would have new work to do, mostly
because the new way would be so much easier. 

Also, the UI's would become cluttered, as now we would have to have 2UI's,
one for v1 support and one for v2 support.

>  From an implementation standpoint, I also worry about combining 
> something like identity revision with all the other IKEv2 changes.  
> You'd essentially be starting from scratch at the next bake-off.  Now 
> I'm not going to claim lots and lots of code reuse between IKEv1 and 
> IKEv2, yet there is some overlap.  But if you completely rototill the 
> identity processing on top of this, you're very close to 
> starting from 
> scratch.  

another good point. The only consolation is that what we'd be starting from
would appear to be MUCH more direct. We would only need to focus on interop
for the format of how we send options 0-5, and not so much the content of
the certs themselves, as that would be an UI matching issue.

> In summary, our strategy of ignoring this has worked so well in the 
> past that I recommend we continue it a while longer.

agreed that we possibly cannot get full consensus, or fully completed text
on this in one week. But I do think we should forgoe the re-work agreed to
above, and fix the protocol know while we still can.

Gregory. 



!! NETSCREEN IS MOVING !! 
New Contact Info starting 2/10:
805 11th Ave, Bldg 3
Sunnyvale, CA  94089
408.543.8002 

+*******************++********************+
Gregory M. Lebovitz
Staff Architect, CTO Office
NetScreen Technologies, Inc.
Ph:   408.730.6002
E:     gregory@netscreen.com
Pg:   page.gregory@netscreen.com
NASDAQ:  NSCN
+*******************++********************+