RE: Security Discussion: Changed Agenda: Teleconference : 12/21/200012:30-4pm CDT : RIM discussion follow-up

["Burdett, David" <david.burdett@commerceone.com>]

Krishna

I think we are close on thinking.

I agree that we can't enforce UN/PW over SSL. However it is really up to the
recipient to decide whether to trust the UN/PW if it has not been sent over
a secure transport. Simply we can't prevent people who have stupid security
policies from making stupid mistakes and if they trust a UN/PW that they
shouldn't have they should not blame ebXML.

I do agree though that we need to develop a number of profiles for security
(and several other areas) so that we can get the interoperability that we
need.

David

-----Original Message-----
From: Krishna Sankar [mailto:ksankar@cisco.com]
Sent: Wednesday, December 27, 2000 12:33 PM
To: Burdett, David
Cc: ebxml-ta-security@lists.ebxml.org; ebXML Transport (E-mail)
Subject: RE: Security Discussion: Changed Agenda: Teleconference :
12/21/200012:30-4pm CDT : RIM discussion follow-up


Hi,

	As usual, comments embedded.

cheers

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Wednesday, December 27, 2000 11:20 AM
> To: 'Krishna Sankar'
> Cc: ebxml-ta-security@lists.ebxml.org; ebXML Transport (E-mail)
> Subject: RE: Security Discussion: Changed Agenda: Teleconference :
> 12/21/200012:30-4pm CDT : RIM discussion follow-up
>
>
> Krishna
>
> A few thoughts ...
>
> You say "We cannot permit the UN/PW in the clear." Why not? If the message
> is sent over SSL then both will be private except to the sender and the
> recipient.
>

The "if" is the keyword here. This is fine so long as we have an end-to-end
SSL implementation. Usually SSL is a point-to-point solution. Another
problem here is that we have to tie in some security implementation with the
UN/PW. Too difficult to check conformance. How can you make sure that when
UN/PW is used, there will be a security transport as well.

<soapbox>
My philosophy on security is that we should cover the normal
implementations - not the corner ones. For that the specs should provide
guidance, a set of default characteristics and flexibility. Which means, the
specs should say what is required, what could be expanded and what could be
plugged-in and out. If we leave everything as optional, there will be
implementations which will have no security and the users might not realize
that. Second thought is, we should provide combinations which make sense and
by default, there will be enough security. Folks, especially SMEs do not
have the time to figure out what is needed and go thru all combinations.
</soapbox>

> You also say "A third issue is the intermediaries like the hub;
> can they see
> the UN/PW?". Again, why not? Sometimes the hub will need to see
> the UN/PW to
> authenticate the sender before forwarding the message.
>
> I don't think we should mandate minimum security levels or that
> security, if
> it is used, MUST be of a certain minimum level. Instead we should enable
> security levels to be used that are approprite to the risks ... and the
> risks vary. Thoughts?

Yep. I agree on this. We can provide different schemes and the associated
risks. The risks are well known, so we can provide references. One can match
the risks and the requirement depending on the messages.

>
> Finally do you have the relevant XML fragments from the 0.8 version of the
> S2ML spec that could be used for UN/PW?
>

I have started working on this. I will try to get one ASAP. Anyway, we
should have one by the first or second week of January.

> Regards
>
> David
>
> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: Wednesday, December 27, 2000 10:31 AM
> To: Burdett, David; ebXML Transport (E-mail)
> Cc: ebxml-ta-security@lists.ebxml.org
> Subject: RE: Security Discussion: Changed Agenda: Teleconference :
> 12/21/200012:30-4pm CDT : RIM discussion follow-up
>
>
> Hi,
>
> 	I agree with you that we should not start another XML structure to
> carry
> the UN/PW. I think the S2ML might be a good candidate. There area
> few issues
> :
>
> 	a)	The standard is not yet ready. May be we can use the 0.8
> version
> 	b)	Sending UN/PW adds another security layer. We cannot permit
> the UN/PW in
> the clear.
> 	c)	A third issue is the intermediaries like the hub; can they
> see the UN/PW
> ? If so, again, we have a security issue.
>
> 	just my 2 yens !
>
> cheers
>
> > -----Original Message-----
> > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > Sent: Wednesday, December 27, 2000 9:37 AM
> > To: ebXML Transport (E-mail)
> > Cc: 'ebxml-ta-security@lists.ebxml.org'
> > Subject: FW: Security Discussion: Changed Agenda: Teleconference :
> > 12/21/200012:30-4pm CDT : RIM discussion follow-up
> >
> >
> > I'm forwarding this to the transport list from the security list.
> >
> > I agree with Zahid that there should be a way inside ebXML headers to
> > include UserId and Password authentication. I don't think that we should
> > reinvent the wheel though.
> >
> > Thoughts?
> >
> > David
> >
> > -----Original Message-----
> > From: Ahmed, Zahid
> > Sent: Wednesday, December 20, 2000 1:40 PM
> > To: Krishna Sankar; ebxml-regrep@lists.ebxml.org;
> > ebxml-ta-security@lists.ebxml.org
> > Subject: RE: Security Discussion: Changed Agenda: Teleconference : 12/21
> > /200012:30-4pm CDT : RIM discussion follow-up
> >
> >
> > > 	Just a few points :
> > >
> > > 	1.	No need for UN/PW
> >
> > I'm concerned that we are not supporting a simple password
> > authentication mechanism which will be very useful for a
> > wide range of clients. Cert-based auth is stonger, but more
> > for simple lookups it is heavy wieght for many apps. We
> > should consider password authentication as an option also
> > because most LDAPs/Databases (and other Reg/Rep efforts, e.g.,
> > UDDI) will support it.
> >
> > thanks,
> > Zahid
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Krishna Sankar [mailto:ksankar@cisco.com]
> > > Sent: Wednesday, December 20, 2000 1:26 PM
> > > To: ebxml-regrep@lists.ebxml.org; ebxml-ta-security@lists.ebxml.org
> > > Subject: RE: Security Discussion: Changed Agenda: Teleconference :
> > > 12/21/200012:30-4pm CDT : RIM discussion follow-up
> > >
> > >
> > > Chris,
> > >
> > > 	Exactly. My suggestion (like yours and others) is to get enough
> > > functionalities thru the current documents and move forward. No new
> > > services.
> > >
> > > 	Just a few points :
> > >
> > > 	1.	No need for UN/PW
> > > 	2.	Don't need rot13 either ;-)
> > >
> > > 	But, looks like there were some discussions at the STC
> > > level and if so, it
> > > is better for all of us to have a separate security con call
> > > and discuss
> > > this.
> > >
> > > 	BTW, I will attend tomorrow's TRP con call for
> > > 8:00-9:00 and also the f2f
> > > in London. I think all the required basics are there, at some
> > > level. We just
> > > need to work out the integration and show a path from here to
> > > there. We can
> > > show that as a part of the regrep security document and refer to your
> > > security document at the appropriate places.
> > >
> > > 	Are you near San Jose ? If so, we could meet and hammer
> > > this out at a
> > > preliminary level. Any suggestions ?
> > >
> > > 	cheers
> > >
> > > > -----Original Message-----
> > > > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > > > Sent: Wednesday, December 20, 2000 1:06 PM
> > > > To: Krishna Sankar
> > > > Cc: ebxml-regrep@lists.ebxml.org; ebxml-ta-security@lists.ebxml.org
> > > > Subject: Re: Security Discussion: Changed Agenda: Teleconference :
> > > > 12/21/200012:30-4pm CDT : RIM discussion follow-up
> > > >
> > > >
> > > > Krishna,
> > > >
> > > > The TR&P MS spec will have a security section. I have sent an early
> > > > draft to the ta-security list and I invite comments/feedback.
> > > >
> > > > This provides for signing (as well as encryption) of messages
> > > > with bindings for XMLDSIG, S/MIME and PGP/MIME. I could add rot13
> > > > too if there is interest;-)
> > > >
> > > > Signing of the message (over a MAC) provides for authentication.
> > > > How is this inadequate? I can understand the need to possibly
> > > > provide for user/password authentication, but that doesn't have
> > > > (IMHO) the requisite strength needed for regrep update access.
> > > >
> > > > However, S2ML does provide a means of conveying credentials
> > > > and they include a mapping for login/password. Maybe we could
> > > > lift what gets published in v0.8 to that purpose.
> > > >
> > > > Bottom line for me is that we NOT reinvent the wheel.
> > > >
> > > > Cheers,
> > > >
> > > > Chris
> > > >
> > > > Krishna Sankar wrote:
> > > > >
> > > > > Yep, we have the security services group by OASIS and Chris is
> > > > right saying
> > > > > that we should work with that group - I have expressed my
> > > interest in
> > > > > participating. As far as I know the S2ML does address
> > > some parts and we
> > > > > could extend the result of the OASIS working group.
> > > > >
> > > > > The question is, what do we do for Release 1 ? Especially as
> > > > the registry
> > > > > requires authentication and sigining of content.
> > > > >
> > > > > cheers
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > > > > > Sent: Wednesday, December 20, 2000 12:26 PM
> > > > > > To: Nieman, Scott
> > > > > > Cc: 'ebxml-regrep@lists.ebxml.org'; 'ebxml-stc@lists.ebxml.org';
> > > > > > ebxml-ta-security@lists.ebxml.org
> > > > > > Subject: Re: Security Discussion: Changed Agenda:
> > > Teleconference :
> > > > > > 12/21/200 012:30-4pm CDT : RIM discussion follow-up
> > > > > >
> > > > > >
> > > > > > Scott,
> > > > > >
> > > > > > When the S2ML initiative was announced, people asked if it
> > > > > > overlapped with the work being done at ebXML.
> > > > > >
> > > > > > The correct, IMHO, answer at that time was: S2ML
> > > defines security
> > > > > > services for authentication and authorization that can
> > > be carried
> > > > > > over any protocol (e.g. SOAP, XP, ebXML). The OASIS TC
> > > formed will
> > > > > > be focused on this very set of services.
> > > > > >
> > > > > > Defining an ebXML Security Service(s) at this time
> > > would be, IMHO,
> > > > > > doing exactly what S2ML was perceived (incorrectly) of doing...
> > > > > > entering a space which is already being addressed by experts in
> > > > > > the field in an OPEN forum (OASIS).
> > > > > >
> > > > > > Now, given that security IS important for RR and that
> > > it is currently
> > > > > > being defined in TR&P, BP, TP and TA (as an overarching
> > > architectural
> > > > > > view
> > > > > > of the works of the other teams), I think that we
> > > should be taking
> > > > > > a close look at what is being defined before launching into
> > > > yet another
> > > > > > specification initiative at this late date in the process.
> > > > > >
> > > > > > >From my point of view, RR is simply a specialized
> > > business process.
> > > > > > If the needs of RR are not being addressed by the BP,
> > > TP and TR&P
> > > > > > specification offerings, then we need to think our work through
> > > > > > more carefully and fill in any gaps that may exist.
> > > > > >
> > > > > > Please, let's not start up yet another splinter group to tackle
> > > > > > an issue that MAY already be addressed within the groups
> > > > > > already focused on security. If anything, the work MUST be
> > > > > > tightly coordinated with the other efforts working on security.
> > > > > >
> > > > > > Please DO keep in mind that once you start down this path, the
> > > > > > next phase you enter will be PKI, and I don't think you want to
> > > > > > go there.
> > > > > >
> > > > > > My $0.02,
> > > > > >
> > > > > > Chris
> > > > > > "Nieman, Scott" wrote:
> > > > > > >
> > > > > > > To follow-up regarding the StC conversation today, I
> > > would like
> > > > > > to invite
> > > > > > > Rik, Marty, Sid, Nick and anyone else to join the scheduled RR
> > > > > > > teleconference tomorrow, to discuss a potential need for a
> > > > > > separate ebXML
> > > > > > > Security Service, specifically to handle authentication,
> > > > encryption, and
> > > > > > > decryption needs.   Messages and payloads could be processed
> > > > > > through this
> > > > > > > service.
> > > > > > >
> > > > > > > RR is concerned about overlap, and general architectural
> > > > > > issues.  At this
> > > > > > > time, RR is specifying this functionality, however, this
> > > > > > functionality is
> > > > > > > also required for normal B2B.  Specifying a single Security
> > > > > > Service would
> > > > > > > enable RR to focus on role-based authorizations,
> > > integrity, etc.
> > > > > > >
> > > > > > > I would like this discussion to last no more than one hour,
> > > > with that
> > > > > > > discussion to be the first topic.
> > > > > > >
> > > > > > > Scott
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Nieman, Scott
> > > [mailto:Scott.Nieman@NorstanConsulting.com]
> > > > > > > Sent:
> > > Tuesday, December 19, 2000 4:35 PM
> > > > > > > To: 'ebxml-regrep@lists.ebxml.org'
> > > > > > > Subject: Teleconference : 12/21/2000 12:30-4pm CDT :
> > > RIM discussion
> > > > > > > follo w-up
> > > > > > >
> > > > > > > Meeting Date: 12/21/2000
> > > > > > > Meeting Time: 12:30-4pm CDT (please note CDT)
> > > > > > >
> > > > > > > The dialup information is:
> > > > > > > USA: 800.892.0357
> > > > > > > Sorry no toll-free for International callers: usa 612.352.7899
> > > > > > > Meeting ID #8186
> > > > > > > 25 locations setup
> > > > > > >
> > > > > > > Agenda: Review the RIM updates based on input from
> > > 12/19 telcon.
> > > > > > >
> > > > > > > Please read the document prior to the call.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Scott
> > > > > >
> > >
> >
>