headers
Jim Basney | 1 Jun 2004 19:33
Picon

BEEP session tuning


Hello,

I'm confused about BEEP session tuning in the SACRED protocol, and I'm
hoping someone can set me straight.  Section 4.1 of RFC 3080 says:

  Note that SASL may provide both user authentication and transport
  security. Once transport security is successfully negotiated for a
  BEEP session, then a SASL security layer must not be negotiated;
  similarly, once any SASL negotiation is successful, a transport
  security profile must not begin its underlying negotiation process.

To me, that says you can't tune with both http://iana.org/beep/TLS and
http://iana.org/SASL/DIGEST-MD5 as suggested in section 3.1 of
draft-ietf-sacred-protocol-bss-09.txt.  Am I misreading that paragraph
of RFC 3080?

-Jim
Permalink | Reply | 1 comment |
headers
RL 'Bob' Morgan | 1 Jun 2004 20:06
Favicon

Re: BEEP session tuning


> I'm confused about BEEP session tuning in the SACRED protocol, and I'm
> hoping someone can set me straight.  Section 4.1 of RFC 3080 says:
>
>   Note that SASL may provide both user authentication and transport
>   security. Once transport security is successfully negotiated for a
>   BEEP session, then a SASL security layer must not be negotiated;
>   similarly, once any SASL negotiation is successful, a transport
>   security profile must not begin its underlying negotiation process.
>
> To me, that says you can't tune with both http://iana.org/beep/TLS and
> http://iana.org/SASL/DIGEST-MD5 as suggested in section 3.1 of
> draft-ietf-sacred-protocol-bss-09.txt.  Am I misreading that paragraph
> of RFC 3080?

You can't use DIGEST-MD5 for a security layer (having previously set up
TLS), meaning you can't use it to do integrity/confidentiality protection
of the data stream.  But you can use it for authentication.  These are
separate features in SASL mechanisms, generally.

 - RL "Bob"
Permalink | Reply | 0 comments |
headers
Stephen Farrell | 15 Jun 2004 18:21
Picon
Picon

BEEP profile ID


All,

Since there were no objections raised to the proposal Magnus made [1],
we have changed the BEEP profile ID for sacred to

        "http://iana.org/beep/sacred"

The RFC should pop out real-soon-now.

Stephen.

[1] http://www.imc.org/ietf-sacred/mail-archive/msg00631.html
Permalink | Reply | 0 comments |
headers
rfc-editor | 21 Jun 2004 20:55
Favicon

RFC 3767 on Securely Available Credentials Protocol


A new Request for Comments is now available in online RFC libraries.

        RFC 3767

        Title:      Securely Available Credentials Protocol
        Author(s):  S. Farrell, Ed.
        Status:     Standards Track
        Date:       June 2004
        Mailbox:    stephen.farrell <at> cs.tcd.ie
        Pages:      25
        Characters: 49552
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-sacred-protocol-bss-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3767.txt

This document describes a protocol whereby a user can acquire
cryptographic credentials (e.g., private keys, PKCS #15 structures)
from a credential server, using a workstation that has locally
trusted software installed, but with no user-specific
configuration.  The protocol's payloads are described in XML.  This
memo also specifies a Blocks Extensible Exchange Protocol (BEEP)
profile of the protocol.  Security requirements are  met by mandating
support for TLS and/or DIGEST-MD5 (through BEEP). 

This document is a product of the Securely Available Credentials
Working Group of the IETF.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane