Issue 1723: SecIOP Architecture (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: In trying to understand some problems we"re having on our reference implementation development, I"ve run across an inconsistency in the CORBAsec V1.2 spec. On page 15-191, Section, 15.9.1, there is a figure 15-59 that shows the SECIOP protocol underneath the IIOP protocol. This is contrary to my understanding of the SECIOP architecture, which corresponds to Figure 15-57 - where the SECIOP protocol is located between the GIOP and IIOP protocols. Hopefully, the problem is simply that Figure 15-59 should have "IIOP" replaced by "GIOP". Resolution: Close issue 1723: SecIOP Architecture Revised Text: Close issue 1723: SecIOP Architecture with the following modifications: Change figure (now 15-58 on page 15-222) to be: -------------------------- -------------------------- | GIOP | | GIOP | | - - - -- - - - - - - | | - - - -- - - - - - - | | fragmentation | | fragmentation | -------------------------- -------------------------- | IIOP | SECIOP | SSLIOP | | IIOP | SECIOP | SSLIOP | ------------------------------------------------------------- | Transport | ------------------------------------------------------------- and Change the "IIOP" in figure 15-60 on page 15-223 to "GIOP". Reason: We agreed to the new picture because describes more acurately the positioning of the protocols, and we agreed to close the issue. Actions taken: July 22, 1998: received issue April 20, 1999: closed issue Discussion: End of Annotations:===== Return-Path: From: "David M. Chizmadia" To: "Mailing List for Security RTF" Subject: SecIOP Architecture Date: Wed, 22 Jul 1998 15:09:38 -0400 X-Msmail-Priority: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 In trying to understand some problems we're having on our reference implementation development, I've run across an inconsistency in the CORBAsec V1.2 spec. On page 15-191, Section, 15.9.1, there is a figure 15-59 that shows the SECIOP protocol underneath the IIOP protocol. This is contrary to my understanding of the SECIOP architecture, which corresponds to Figure 15-57 - where the SECIOP protocol is located between the GIOP and IIOP protocols. Hopefully, the problem is simply that Figure 15-59 should have "IIOP" replaced by "GIOP". Comments? -DMC Return-Path: X400-Received: by mta tutartis in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; Relayed ; Thu, 23 Jul 98 12:21:52 +0100 X400-Received: by mta man23xc in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Thu, 23 Jul 98 12:12:58 +0100 X400-Received: by mta man0506 in /PRMD=icl/ADMD=gold 400/C=GB/ ; converted ({ 1 3 12 2 1001 1 0 4 300 0 507 }) ; Relayed ; Thu, 23 Jul 98 12:22:43 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Thu, 23 Jul 98 12:22:43 +0100 Date: Thu, 23 Jul 98 12:22:43 +0100 X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000042400015014] X400-Originator: "NC Battle" X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) Original-Encoded-Information-Types: { 1 3 12 2 1001 1 0 4 300 0 707 } Content-Identifier: 15014 Priority: normal From: "NC Battle" To: dmc@tycho.ncsc.mil Cc: sec-rev@omg.org References: <01bdb5a4$45f54d90$1b033390@moccasin.tycho.ncsc.mil> Importance: normal Subject: RE: SecIOP Architecture > On page 15-191, Section, 15.9.1, there is a figure 15-59 that shows the SECIOP protocol underneath the IIOP protocol. This is contrary to my understanding of the SECIOP architecture, which corresponds to Figure 15-57 - where the SECIOP protocol is located between the GIOP and IIOP protocols. I've always found this very confusing. I think the reason is that there are two different sorts of "underneath" going on here - but I'd be more than happy to be corrected! IIOP is "underneath" GIOP in the sense that it's a specialization or mapping of the general protocol onto a TCP/IP transport. So for example the IIOP part of the Architecture introduces IP addresses and ports in the IOR. SECIOP is "underneath" GIOP in the sense that fragments of a GIOP message are disassembled, transported and re-assembled at the other end (having been protected en-route, and with a context establishment exchange that GIOP knows nothing about). I think these two are different sorts of "underneathness", so it's difficult to draw one diagram with GIOP, SECIOP and IIOP and their relative positions. Is SECIOP transport protocol independent? I would say yes, so it is a bit like GIOP, but sits underneath it in the sense that it transports GIOP fragments (securely). In practice, SECIOP will be run over TCP/IP, and targetted at IORs that have IIOP details, so there is a sort of "ISECIOP" protocol which sits below IIOP since it transports IIOP fragments over a TCP/IP connection. I apologise if this is all nonsense, but as I said I've always found this area very confusing. -nick Return-Path: From: "David M. Chizmadia" To: "NC Battle" Cc: Subject: Re: SecIOP Architecture Date: Thu, 23 Jul 1998 09:06:17 -0400 X-Msmail-Priority: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Nick, In answer to at least one of you questions: yes, SECIOP is transport-protocol-independent. Based on multiple, definitive statements from my colleagues-with-a-clue, Figure 15-57 is the normative diagram of the SECIOP architecture. My observation is simply that 15-57 and 15-59 are inconsistent. -DMC PS: As an aside, who at ICL is the best person to contact regarding the DAIS Security product architecture. I'm in the process of drafting an RFP to refine the SECIOP spec so that system interoperability is possible and I'd like to make sure that ICL, as SECIOP and SESAME champion, is involved. -DMC -----Original Message----- From: NC Battle To: dmc@tycho.ncsc.mil Cc: sec-rev@omg.org Date: Thursday, July 23, 1998 7:31 AM Subject: RE: SecIOP Architecture >> On page 15-191, Section, 15.9.1, there is a figure > 15-59 that shows the SECIOP protocol underneath the > IIOP protocol. This is contrary to my understanding > of the SECIOP architecture, which corresponds to > Figure 15-57 - where the SECIOP protocol is located > between the GIOP and IIOP protocols. > >I've always found this very confusing. I think the reason is >that there are two different sorts of "underneath" going on >here - but I'd be more than happy to be corrected! > >IIOP is "underneath" GIOP in the sense that it's a specialization >or mapping of the general protocol onto a TCP/IP transport. So >for example the IIOP part of the Architecture introduces IP addresses >and ports in the IOR. > >SECIOP is "underneath" GIOP in the sense that fragments of a >GIOP message are disassembled, transported and re-assembled at the >other end (having been protected en-route, and with a context >establishment exchange that GIOP knows nothing about). > >I think these two are different sorts of "underneathness", so it's >difficult to draw one diagram with GIOP, SECIOP and IIOP and their >relative positions. > >Is SECIOP transport protocol independent? I would say yes, so it is >a bit like GIOP, but sits underneath it in the sense that it transports >GIOP fragments (securely). In practice, SECIOP will be run over TCP/IP, >and targetted at IORs that have IIOP details, so there is a sort of >"ISECIOP" protocol which sits below IIOP since it transports IIOP >fragments over a TCP/IP connection. > >I apologise if this is all nonsense, but as I said I've always found >this area very confusing. > >-nick Sender: jis@fpk.hp.com Message-ID: <37B316A0.7A22DEFF@fpk.hp.com> Date: Thu, 12 Aug 1999 14:46:56 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: sec-rev@omg.org CC: interop@omg.org Subject: Relation between IIOP/GIOP, SSLIOP, SECIOP References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: e5f69ee5a703d5043eb0ac058392e3b1 The resoltuion of issue 1723 as voted on in the Security RTF says: Action: Close issue 1723: SecIOP Architecture with the following modifications: Change figure (now 15-58 on page 15-222) to be: -------------------------- -------------------------- | GIOP | | GIOP | | - - - -- - - - - - - | | - - - -- - - - - - - | | fragmentation | | fragmentation | -------------------------- -------------------------- | IIOP | SECIOP | SSLIOP | | IIOP | SECIOP | SSLIOP | ------------------------------------------------------------- | Transport | ------------------------------------------------------------- and Change the "IIOP" in figure 15-60 on page 15-223 to "GIOP". Reason: We agreed to the new picture because describes more acurately the positioning of the protocols, and we agreed to close the issue. _______________________________________________________________ I am sitting here a scratching my head about this probably minor thing. IIOP and SECIOP are distinct protocols in the sense that the "magic" field in GIOP header are distinct for these two, "GIOP" for GIOP and "SECP" for SECIOP. The magic field specifies which message set is applicable to the rest of the message. So in terms of admissible message sets SECIOP is a distinct protocol from GIOP, but which happens to use the same header format as GIOP and the same encoding rules as GIOP. Now, SSLIOP in that sense is not a distinct protocol at all at this level. It is just IIOP with a specific TAG. So in some sense it seems to me that a more correct representation of this complex situation should look something like: -------------------------- -------------------------- | GIOP | | GIOP | | - - - -- - - - - - - | | - - - -- - - - - - - | | fragmentation | | fragmentation | -------------------------- -------------------------- | IIOP | SECIOP | | IIOP | SECIOP | |- - - - | | | |- - - - | | | | SSLIOP | | | | SSLIOP | | | |------------------------| |------------------------| | SSL | | | SSL | | |--------- | |--------- | | IP | | IP | ------------------------------------------------------------- | Link | ------------------------------------------------------------- I am just trying to clarify the model in my head, and I am not necessarily saying that the figure in the resolution needs to change, although I believe that it actually does not reflect the relationship of the protocols accurately. Perhaps a paragraph of explanation could be added to explain the complex relationship. Any thoughts, comments etc. from the protocol experts? Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Message-ID: <37B31953.7B1F2B92@fpk.hp.com> Date: Thu, 12 Aug 1999 14:58:27 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: sec-rev@omg.org, interop@omg.org Subject: Relation between IIOP/GIOP, SSLIOP, SECIOP 2nd try. References: <37B316A0.7A22DEFF@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 03b0a35ed14908fa3969e1868af7a7c5 OK, another try. The figure got mushed in the last attempt due to the brain-deadness of the mailer:-( The resoltuion of issue 1723 as voted on in the Security RTF says: Action: Close issue 1723: SecIOP Architecture with the following modifications: Change figure (now 15-58 on page 15-222) to be: -------------------------- -------------------------- | GIOP | | GIOP | | - - - -- - - - - - - | | - - - -- - - - - - - | | fragmentation | | fragmentation | -------------------------- -------------------------- | IIOP | SECIOP | SSLIOP | | IIOP | SECIOP | SSLIOP | --------------------------------------------------------- | Transport | --------------------------------------------------------- and Change the "IIOP" in figure 15-60 on page 15-223 to "GIOP". Reason: We agreed to the new picture because describes more acurately the positioning of the protocols, and we agreed to close the issue. _______________________________________________________________ I am sitting here a scratching my head about this probably minor thing. IIOP and SECIOP are distinct protocols in the sense that the "magic" field in GIOP header are distinct for these two, "GIOP" for GIOP and "SECP" for SECIOP. The magic field specifies which message set is applicable to the rest of the message. So in terms of admissible message sets SECIOP is a distinct protocol from GIOP, but which happens to use the same header format as GIOP and the same encoding rules as GIOP. Now, SSLIOP in that sense is not a distinct protocol at all at this level. It is just IIOP with a specific TAG. So in some sense it seems to me that a more correct representation of this complex situation should look something like: -------------------------- -------------------------- | GIOP | | GIOP | | - - - -- - - - - - - | | - - - -- - - - - - - | | fragmentation | | fragmentation | -------------------------- -------------------------- | IIOP | SECIOP | | IIOP | SECIOP | |- - - - | | | |- - - - | | | | SSLIOP | | | | SSLIOP | | | |------------------------| |------------------------| | SSL | | | SSL | | |--------- | |--------- | | IP | | IP | --------------------------------------------------------- | Link | --------------------------------------------------------- I am just trying to clarify the model in my head, and I am not necessarily saying that the figure in the resolution needs to change, although I believe that it actually does not reflect the relationship of the protocols accurately. Perhaps a paragraph of explanation could be added to explain the complex relationship. BTW, this also clearly shows that IIOP => IP. Any thoughts, comments etc. from the protocol experts? Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Message-ID: <37B331A5.6355DD2A@fpk.hp.com> Date: Thu, 12 Aug 1999 16:42:13 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Polar Humenn CC: sec-rev@omg.org, interop@omg.org Subject: Re: Relation between IIOP/GIOP, SSLIOP, SECIOP 2nd try. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: fbab80e143d18159b1385bda91ae34d0 Polar Humenn wrote: > > Well, you can draw the picture many many different ways. Already I > think > you can see that the picture you drew is also getting very > complicated. > You also forgot the TCP component. Yes, I meant to write TCP/IP. Sorry about that. > But we only wanted to convey a small point that the three protocols were > basically different, but all provided "transport" for GIOP (so, IIOP is > really a pass thru). I guess the loose use of the word "transport" is what confuses me. > (1) IIOP == GIOP stacked over TCP/IP > > (2) SECIOP is just SECIOP and can be stacked over any transport. Doesn't the "transport" on which SECIOP is hosted have to provide TCP/IP like properties, i.e. bytes are delivered in the sequence in which they are fed in etc.? If that is the case then strictly speaking "any transport" is incorrect. > (3) GIOP can be stacked over SECIOP. > > (4) SECIOP can be intermixed with GIOP over the same transport. By "transport" here do you mean something like a TCP/IP connection? > (5) SSLIOP is SSL over TCP/IP. Isn't it IIOP over SSL over TCP/IP? Otherwise why the IOP in the name? > (6) GIOP can be stacked over SSLIOP > > (7) SSLIOP and GIOP cannot be intermixed over the same transport. What does this mean? Is it saying that a raw IIOP stream and an SSLIOP stream cannot be intermixed in the same TCP/IP "connection"? > A difficult task at best, but the picture would be so complicated, it > wouldn't be really usefull. I know. I am just wondering whether it confuses more than it illuminates. Perhaps simply removing SSLIOP from that figure and merely explaining the relationship between GIOP and SECIOP only would be a good thing. Why add more complication to an already complicated situation. Afterall, there is no other mention of SSLIOP anywhere else in that section of the document. It suddenly appears in that figure without any explanation at all. Were you planning to propose additional explanatory text for the expanded figure as proposed in the resolution of 1723? Otherwise I think the reader of the chapter is left quite confused. Perhaps we could remove SSLIOP from that figure and then add items 1 through 4 above as part of some explanantory text. Then we could do a separate figure in the same spirit and insert it in section 15.14 "Integrating SSL with CORBA". Indeed, if we are very ambitious, then at that point even the more complete figure could be attempted because there one can provide a reference back to the SECIOP section. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 12 Aug 1999 17:04:53 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: sec-rev@omg.org, interop@omg.org Subject: Re: Relation between IIOP/GIOP, SSLIOP, SECIOP 2nd try. In-Reply-To: <37B331A5.6355DD2A@fpk.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 491d70f0a24985edb37f3063bb6fed2c On Thu, 12 Aug 1999, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > Well, you can draw the picture many many different ways. Already I > think > > you can see that the picture you drew is also getting very > complicated. > > You also forgot the TCP component. > > Yes, I meant to write TCP/IP. Sorry about that. > > > But we only wanted to convey a small point that the three > protocols were > > basically different, but all provided "transport" for GIOP (so, > IIOP is > > really a pass thru). > > I guess the loose use of the word "transport" is what confuses me. > > > (1) IIOP == GIOP stacked over TCP/IP > > > > (2) SECIOP is just SECIOP and can be stacked over any transport. > > Doesn't the "transport" on which SECIOP is hosted have to provide > TCP/IP > like properties, i.e. bytes are delivered in the sequence in which > they > are fed in etc.? If that is the case then strictly speaking "any > transport" is incorrect. Would "reliable connection based transport" be correct? > > (3) GIOP can be stacked over SECIOP. > > > > (4) SECIOP can be intermixed with GIOP over the same transport. > > By "transport" here do you mean something like a TCP/IP connection? Yes. > > (5) SSLIOP is SSL over TCP/IP. > > Isn't it IIOP over SSL over TCP/IP? Otherwise why the IOP in the > name? Well, it might have said that, but I can't do the math and come up with the same answer. IIOP profile provides the host name, SSLIOP component provides the port number, and SSL provides the secure association, and TCP/IP provides the "connection". How would you draw that? > > (6) GIOP can be stacked over SSLIOP > > > > (7) SSLIOP and GIOP cannot be intermixed over the same transport. > > What does this mean? Is it saying that a raw IIOP stream and an > SSLIOP > stream cannot be intermixed in the same TCP/IP "connection"? Well, being an IIOP stream is really a GIOP stream. So, what you are talking about is mixing GIOP packets and SSL packets. I guess it can be done. Why not? I'll withdraw 7. > > A difficult task at best, but the picture would be so complicated, it > > wouldn't be really usefull. > > I know. I am just wondering whether it confuses more than it > illuminates. Perhaps simply removing SSLIOP from that figure and merely > explaining the relationship between GIOP and SECIOP only would be a good > thing. Why add more complication to an already complicated situation. > Afterall, there is no other mention of SSLIOP anywhere else in that > section of the document. It suddenly appears in that figure without any > explanation at all. Were you planning to propose additional explanatory > text for the expanded figure as proposed in the resolution of 1723? > Otherwise I think the reader of the chapter is left quite confused. > Perhaps we could remove SSLIOP from that figure and then add items 1 > through 4 above as part of some explanantory text. Sounds good to me. You want to do the write up? > Then we could do a separate figure in the same spirit and insert it in > section 15.14 "Integrating SSL with CORBA". Indeed, if we are very > ambitious, then at that point even the more complete figure could be > attempted because there one can provide a reference back to the SECIOP > section. Again, can you do the write up? Okay, I'm outta here for the weekend. See you monday. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Sender: jis@fpk.hp.com Message-ID: <37B33B8B.761C0467@fpk.hp.com> Date: Thu, 12 Aug 1999 17:24:27 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Polar Humenn CC: sec-rev@omg.org, interop@omg.org Subject: Re: Relation between IIOP/GIOP, SSLIOP, SECIOP 2nd try. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6a7916a59039fd64542e7667e618cc38 > Well, being an IIOP stream is really a GIOP stream. So, what you are > talking about is mixing GIOP packets and SSL packets. I guess it can > be > done. Why not? I'll withdraw 7. > > > > A difficult task at best, but the picture would be so > complicated, it > > > wouldn't be really usefull. > > > > I know. I am just wondering whether it confuses more than it > > illuminates. Perhaps simply removing SSLIOP from that figure and > merely > > explaining the relationship between GIOP and SECIOP only would be > a good > > thing. Why add more complication to an already complicated > situation. > > Afterall, there is no other mention of SSLIOP anywhere else in > that > > section of the document. It suddenly appears in that figure > without any > > explanation at all. Were you planning to propose additional > explanatory > > text for the expanded figure as proposed in the resolution of > 1723? > > Otherwise I think the reader of the chapter is left quite > confused. > > > Perhaps we could remove SSLIOP from that figure and then add items > 1 > > through 4 above as part of some explanantory text. > > Sounds good to me. > You want to do the write up? > > > Then we could do a separate figure in the same spirit and insert > it in > > section 15.14 "Integrating SSL with CORBA". Indeed, if we are very > > ambitious, then at that point even the more complete figure could > be > > attempted because there one can provide a reference back to the > SECIOP > > section. > > Again, can you do the write up? I'll take a crack at it. Will have something by the San Jose meeting to discuss. That figure has been unsatisfactory in the past and it seems to have gotten more confusingly unsatisfactory in the revised form. I did vote for that change, but now I can't understand it myself anymore:-( Oh well.... Have a good weekend Polar, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA.