headers
Stephen Farrell | 6 Nov 2001 18:51
Picon

I-D ACTION:draft-burdis-cat-srp-sasl-05.txt


FYI - the SASL-SRP draft has been re-issued.

Stephen.

http://www1.ietf.org/mail-archive/ietf-announce/Current/msg15089.html
--

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell <at> baltimore.ie
Ireland                             http://www.baltimore.com
Permalink | Reply | 0 comments |
headers
Gareth Richards | 22 Nov 2001 09:17

SACRED Protocol


I have been going through the SACRED mail archive to try and get an
understanding of how SACRED will handle authentication and transport and I
wanted to check that I understand the current situation.

The proposal appears to be that SACRED will rely on the built-in security
of the transport and so will be limited in the transport systems it can
use.  Since BEEP can use the SASL-SRP mechanism to provide both mutual
authentication and a session encryption key it can be used.  Isn't this
approach, rather than having a self-contained protocol specifying the use
of SASL, going to cause problems if other transport protocols such as
XML-Protocol are used?

For example, I've noticed that the draft charter for the W3C XKMS WG [1]
proposes "harmonizing the SACRED protocol layer with the X-KRSS roaming
operation".  It could be desirable for the same technology to be applied
for this purpose in both environments.  It seems, however, that XKMS is
likely to specify XML-Protocol as its initial binding and to follow an
approach where security sublayers (XMLDSig, XML Encryption) are directly
applied to the XKMS application protocol, rather than being consumed from
an underlying transport.

[1]
http://lists.w3.org/Archives/Public/www-xkms-ws/2001Oct/att-0011/01-xkms-ch
arter.html

Gareth Richards

RSA Security
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eamon O'Tuathail | 22 Nov 2001 11:20

RE: SACRED Protocol


BEEP is designed so that it can run across multiple transports, based on
a transport mapping (section 2.5 of RFC 3080).  

RFC3081 defines one transport mapping to TCP, and similar mappings are
possible for other transports (e.g. SCTP).  

Hence, SACRED over BEEP is transport-independent. It can work with any
transport mapping defined under BEEP. 

Eamon O'Tuathail
http://www.clipcode.com
Permalink | Reply | 2 comments |
headers
Gareth Richards | 22 Nov 2001 16:15

RE: SACRED Protocol


When I referred to transport protocols, I meant the messaging frameworks
such as SOAP or BEEP.  It is true that BEEP can run on top of different
transport protocols but the issue I was raising was that the current SAML
draft seems to blur the distinction between these frameworks and the
authentication protocols such as SASL.

Sorry for the misunderstanding.

> -----Original Message-----
> From: owner-ietf-sacred <at> mail.imc.org
> [mailto:owner-ietf-sacred <at> mail.imc.org]On Behalf Of Eamon O'Tuathail
> Sent: 22 November 2001 10:20
> To: 'Gareth Richards'; ietf-sacred <at> imc.org
> Subject: RE: SACRED Protocol
>
>
>
>
> BEEP is designed so that it can run across multiple transports, based on
> a transport mapping (section 2.5 of RFC 3080).
>
> RFC3081 defines one transport mapping to TCP, and similar mappings are
> possible for other transports (e.g. SCTP).
>
> Hence, SACRED over BEEP is transport-independent. It can work with any
> transport mapping defined under BEEP.
>
> Eamon O'Tuathail
> http://www.clipcode.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gareth Richards | 22 Nov 2001 16:32

RE: SACRED Protocol


I of course meant SACRED not SAML!

Sorry for even more confusion.

>
> When I referred to transport protocols, I meant the messaging frameworks
> such as SOAP or BEEP.  It is true that BEEP can run on top of different
> transport protocols but the issue I was raising was that the current SAML
> draft seems to blur the distinction between these frameworks and the
> authentication protocols such as SASL.
>
> Sorry for the misunderstanding.
>
> > -----Original Message-----
> > From: owner-ietf-sacred <at> mail.imc.org
> > [mailto:owner-ietf-sacred <at> mail.imc.org]On Behalf Of Eamon O'Tuathail
> > Sent: 22 November 2001 10:20
> > To: 'Gareth Richards'; ietf-sacred <at> imc.org
> > Subject: RE: SACRED Protocol
> >
> >
> >
> >
> > BEEP is designed so that it can run across multiple
> transports, based on
> > a transport mapping (section 2.5 of RFC 3080).
> >
> > RFC3081 defines one transport mapping to TCP, and similar mappings are
> > possible for other transports (e.g. SCTP).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Nystrom | 26 Nov 2001 19:51

The future of SACRED


Dear WG,

A second version of SACRED's protocol I-D was posted about four weeks
ago. To date, we have received only one comment on this draft. The
first version received very limited feedback too, which brought us to
ask, at the IETF in London, whether we have a broad enough
constituency to continue the work towards a standards-track document.

Given the continued low level of interaction on the mailing list, we
would therefore once again like to ask those of you who are interested
in developing a standards track protocol to step forward and
express your interest and willingness to contribute to the quality
of the solution. We feel that we would need this support from a
reasonable number of independent members of the group in order to
continue the work towards a standards-track RFC. If we don't get this
confirmation, our plan is to move the SACRED protocol document to
experimental track RFC sometime early next year (after a WG last
call).

Please send an email to the list before the IETF meeting in SLC (and
better yet include your comments on the current draft), so that we
know at the meeting whether the main topic to discuss is WG status or
the comments on the protocol draft.

Best regards,
-- Magnus and Stephen
Permalink | Reply | 5 comments |
headers
Stephen Farrell | 28 Nov 2001 19:51
Picon

Re: The future of SACRED


I know we said "before SLC" in that mail, but 48 hours 
later and no reaction at all tells me something:-)

Assuming no change from this, we'll be working to the 
following schedule:

- Discuss current drafts in SLC
- Re-issue in early/mid Jan (basically asap given the
  holidays)
- Issue 2 week WG last call
- Send to IESG after resolution of the (likely few:-)
  last call comments (possibly early Feb)
- WG goes dormant, then shuts-down when RFC(s)
  issue(s)

I'm ok with that schedule for the protocol draft. 
Any problems for the framework authors?

Stephen.

Magnus Nystrom wrote:
> 
> Dear WG,
> 
> A second version of SACRED's protocol I-D was posted about four weeks
> ago. To date, we have received only one comment on this draft. The
> first version received very limited feedback too, which brought us to
> ask, at the IETF in London, whether we have a broad enough
> constituency to continue the work towards a standards-track document.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Menno Pieters | 28 Nov 2001 22:09
Picon

Re: The future of SACRED


At 18:51 +0000 28-11-2001, Stephen Farrell wrote:
>I know we said "before SLC" in that mail, but 48 hours
>later and no reaction at all tells me something:-)

Stephen/Magnus,

You're right the list has been a bit too silent. However, I still 
think it is an interesting initiative.

I won't be in SLC, but perhaps I can give some comments on the draft, 
before the meeting. At least I've taken the first step, downloaded 
and printed the draft, so I can read it in my own time and perhaps 
comment on it... :-)

So, please DO continue you're efforts!

Thanks and regards,

Menno Pieters

<CUT>
--

-- 
---------------------------------------------------
Menno Pieters
M&I/STELVIO bv - Adviseurs voor Internettechnologie
Postbus 2171             |              Zonnehof 41
3800 CD Amersfoort       |      3811 ND  Amersfoort
The Netherlands
telefoon/phone: +31-33-4.349.340
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ariel Sobelmen | 29 Nov 2001 15:46

The future of SACRED


Hi all,

I'm new on this list and realize I'm jumping into the middle of a discussion
I know little about.  I am chair of WAP Forum's E-commerce Expert Group
(ECOMEG) and have been exchanging private e-mails with a number of members
of your group during the last few days.  Essentially, in the next ECOMEG
meetings we will be trying to address the business questions surrounding the
need for availability of credentials and the various use-cases in which such
availability will be required.

Looking around at the work being done, I have not come across many other
groups which produced work on this topic.  I would think that there can be
great value in learning more about what each group is doing, and this can be
quite useful for us at the WAP Forum/ECOMEG to understand the work further
and see if there is need and interest to coordinate this work with WAP work
and specifications.

Therefore, although I am not sure what dormant and shutdown mean in the IETF
working group context, it doesn't sound like a great thing... :-)

I'd like to suggest that some exploration of potential cooperation be
examined.  Unfortunately, I will not be able to attend SLC meeting.
However, during the upcoming WAP Forum meeting (December 2-6, Berlin), I
will check who from ECOMEG will be attending SLC and see if we can
coordinate an attendee to your group.  I would also like to encourage a
presentation of SACRED work to ECOMEG (and possibly check with WAP Security
working group - WSG if they would be interested in this too).

Thanks, Ariel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dale Gustafson | 29 Nov 2001 18:41

Re: The future of SACRED


Hi Magnus and Stephen,

I apologize for not getting back to you sooner on this -- I've been out of town
much of the last month so have not been able to follow up on this.

I'd like to see the protocol document progress to standards track status.  I
believe there's real value in a standardized, general purpose secure credential
exchange capability that can be implemented in a wide range of internet devices.

I was only able to take a brief look at the latest revision and jot down a few
comments.  I'll revisit those and send to the list if there's anything of
substance in them.  I recall that this latest revision appeared to backtrack on
several important technical issues (capabilities that some of us had articulated
earlier reappeared albeit somewhat unexpectedly  :-).

Net-net, I believe the latest revision of the protocol document is a substantial
improvement over the previous and would like to see it driven to completion.
FWIW, I also think it might help if the rationale behind recent changes that
appear to be driven by parallel work in W3's XKMS area were more fully explained
to the group.  Without a little more background information, it may be difficult
for many/most to provide meaningful comments.

Best Regards,

Dale Gustafson
Future Foundation Inc.
+1 651 452-9033 office
+1 218 343-9724 mobile
(Continue reading)

Permalink | Reply | 1 comment |

Gmane