RE: D-AR0062.2: Authentication for data

> -----Original Message-----
> From: David Booth [mailto:dbooth@w3.org]
> Sent: Sunday, May 05, 2002 6:26 PM
> To: Joseph Hui; ECKERT,ZULAH (HP-Cupertino,ex1); Bick, Bob (LNG); Hugo
> Haas; www-ws-arch@w3.org
> Subject: RE: D-AR0062.2: Authentication for data
> 
> 
> If I am understanding your explanation, it sounds like "data 
> authentication" basically boils down to:
> 
>          "data authentication" = "data integrity" + sender 
> authentication

Basically, yes.  Entirely?  Not quite.
For all practical purpose receiver authentication is often implicitly
assumed; but it doesn't make the above expression a solid one.
In channel based approaches, the assumption is pretty much inherent.
E.g. in SSL/TLS, at least one peer -- the server -- is authenticated 
(during handshake) prior to any application data transfer.  The other
peer is authenticated either by the server's stipulating "Client
Authentication (by certificate)" during handshake or some application
level client authc means after handshake, such as user/password,
challenge response, critical data submission (e.g. disclosing one's
credit card number), ...
The same can't be said of object (or message) based approaches,
say xmlenc.  (This may be why "sender authentication" tends to
be more conspicuously emphasized in message based approaches.)

> Thanks for the explanation.

Sure, my pleasure.
 
> In any case, I think it would be helpful to re-word 
> requirement D-AR0062.2, 
> to explicitly separate out and identify the issues of "data 
> integrity" and "sender authentication".

Data integrity is covered in D-AR006.5.  
One can stretch D-AR006.2.1 to cover "Sender authentication".
But IMO it's cleaner to leave D-AR006.2.1 as a discrete req.
I was aware of the overlap when I wrote this; but tiling the
reqs for the sake of avoiding overlap alone appeared to me
unsound at the time.

Of course I'm open to new verbiage anyone may suggest, *in
complete sentence(s)*.

Cheers,

Joe Hui
Exodus, a Cable & Wireless service
==============================================

> 
> At 11:43 AM 5/3/2002 -0700, Joseph Hui wrote:
> > > -----Original Message-----
> > > From: ECKERT,ZULAH (HP-Cupertino,ex1) [mailto:zulah_eckert@hp.com]
> > > Sent: Friday, May 03, 2002 11:02 AM
> > > To: Joseph Hui; Bick, Bob (LNG); Hugo Haas; www-ws-arch@w3.org
> > > Cc: ECKERT,ZULAH (HP-Cupertino,ex1)
> > > Subject: RE: D-AR0062.2: Authentication for data
> > >
> > > Joe,
> > >
> > > Isn't this commonly refered to as Data Origin Authentication
> > > (as opposed to "data authentication")?
> >
> >Not exactly, though in some loose context some writers treat the two 
> >interchangeably.
> >Here's the nuance.  Data Origin Authentication is more like 
> confirming
> >to Bob that the data came from Alice, but it doesn't tell whether the
> >data has been altered (so Bob doesn't have to compute the checksum or
> >message digest for verifying data integrity.)  Of course, in 
> real life
> >what good is to Bob to know the message came from Alice but not know
> >if the message has been altered, if Bob and Alice are serious about
> >security?  This leads to data authentication.
> >Data authentication means confirming to Bob the data came 
> from Alice and it
> >has not been altered.  It encompasses Data origin authc and 
> data integrity.
> >E.g. Alice and Bob did a TLS handshake, through their sharing of
> >a master secret, they share a set of keying material for deriving
> >the symmetric keys known only between them.
> >One of the symmetric keys is for computing the HMAC-SHA1, say H.
> >Before sending a message M to Bob, Alice computes a message digest
> >with HMAC-SHA1, which is a message digest algorithm incorporating H,
> >resulting in D.  Alice sends M and D to Bob.  (Note that M can be in
> >either plaintext or ciphertext, depending on if Alice and Bob see a
> >need for Confidentiality.)  Bob now hashes M with H to get d.
> >If d == D, then voila -- Bob knows M came from Alice unaltered.
> >
> >Joe Hui
> >Exodus, a Cable & Wireless service
> >=============================================
> >
> > >
> > > Zulah
> > > Hewlett-Packard Company
> > >
> > > -----Original Message-----
> > > From: Joseph Hui [mailto:jhui@digisle.net]
> > > Sent: Friday, May 03, 2002 9:07 AM
> > > To: Bick, Bob (LNG); Hugo Haas; www-ws-arch@w3.org
> > > Subject: RE: D-AR0062.2: Authentication for data
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bick, Bob (LNG) [mailto:robert.bick@lexisnexis.com]
> > > [snip]
> > > > I'd suggest we use the standard terms "data integrity" and
> > > > "non-repudiation"
> > > > in that case rather than "data authentication". Perhaps this
> > > > may be more
> > > > clear.
> > >
> > > Data authentication IS a widely understood (or standard, if
> > > you so chose) term.
> > >
> > > Do not confuse "data integrity" and "non-repudiation" with
> > > data authentication.  They are not the same.
> > >
> > > Joe Hui
> > > Exodus, a Cable & Wireless service
> > > ==========================================
> > > >
> > > > Bob
> > > >
> > > > -----Original Message-----
> > > > From: Joseph Hui [mailto:jhui@digisle.net]
> > > > Sent: Thursday, May 02, 2002 9:12 PM
> > > > To: Hugo Haas; www-ws-arch@w3.org
> > > > Subject: RE: D-AR0062.2: Authentication for data
> > > >
> > > >
> > > > Data authentication -- authenticate that the data came from
> > > the right
> > > > source.
> > > > Getting acquainted with HMAC may help further.
> > > >
> > > > E.g. asking you to produce a driver's license 
> authenticates you (by
> > > > biometrics)
> > > > to me that you're Hugo.  That's __peer (or party, or source)
> > > > authentication__.
> > > > Computing the hash of a message that incorporates a secret
> > > > shared by you and
> > > > me
> > > > allows me to authenticate that the message has not been
> > > altered and it
> > > > came from you.  That's __data authentication__.  HMAC is one
> > > > way of doing
> > > > this.
> > > > Digital Signature is another way; but it requires Public Key
> > > > Encryption
> > > > (PKE),
> > > > thus a bit more expensive.
> > > >
> > > > Joe Hui
> > > > Exodus, a Cable & Wireless service
> > > > ==================================================
> > > > > -----Original Message-----
> > > > > From: Hugo Haas [mailto:hugo@w3.org]
> > > > > Sent: Thursday, May 02, 2002 2:02 PM
> > > > > To: www-ws-arch@w3.org
> > > > > Subject: D-AR0062.2: Authentication for data
> > > > >
> > > > >
> > > > > My apologies, I was talking about D-AR0062.2, not D-AR006.2.1.
> > > > >
> > > > > * Hugo Haas <hugo@w3.org> [2002-05-02 16:59-0400]
> > > > > > D-AR0062.2 reads:
> > > > > >
> > > > > >           + D-AR0062.2 The security framework must include
> > > > > Authentication
> > > > > >             for data (sent and received by
> > > communicating parties).
> > > > > >
> > > > > > D-AR0062.1 talks about parties authentication. D-AR0062.5
> > > > > talks about
> > > > > > data integrity. It is not clear to me what data
> > > authentication is.
> > > > >
> > > > > --
> > > > > Hugo Haas - W3C
> > > > > mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ -
> > > > > tel:+1-617-452-2092
> > > > >
> > > > >
> > > >
> > >
> 
> -- 
> David Booth
> W3C Fellow / Hewlett-Packard
> Telephone: +1.617.253.1273
> 
>

Received on Tuesday, 7 May 2002 16:36:22 UTC