141 lines
7.9 KiB
HTML
141 lines
7.9 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="Using per-message services" />
|
||
|
|
<meta name="abstract" content="After establishing a security context, two communicating peers can exchange secure messages over the established context." />
|
||
|
|
<meta name="description" content="After establishing a security context, two communicating peers can exchange secure messages over the established context." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzahajgssdev10.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzahajgssdev1060.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzahajgssdev1080.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzahajgssdev1070" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Using per-message services</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzahajgssdev1070"><a name="rzahajgssdev1070"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Using per-message services</h1>
|
||
|
|
<div><p>After establishing a security context, two communicating peers
|
||
|
|
can exchange secure messages over the established context.</p>
|
||
|
|
<p>Either peer can originate a secure message, regardless of whether it served
|
||
|
|
as initiator or acceptor when establishing context. To make the message secure, IBM<sup>®</sup> JGSS
|
||
|
|
computes a cryptographic message integrity code (MIC) over the message. Optionally, IBM JGSS
|
||
|
|
can have the Kerberos V5 mechanism encrypt the message to help ensure privacy.</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Sending messages</h4><p>IBM JGSS provides two sets of methods for
|
||
|
|
securing messages: wrap() and getMIC(). </p>
|
||
|
|
<p><strong>Using wrap()</strong></p>
|
||
|
|
<div class="p">The
|
||
|
|
wrap method performs the following actions: <ul><li>Computes an MIC</li>
|
||
|
|
<li>Encrypts the message (optional)</li>
|
||
|
|
<li>Returns a token</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<p> The calling application uses the MessageProp class in conjunction
|
||
|
|
with GSSContext to specify whether to apply encryption to the message.</p>
|
||
|
|
<p>The
|
||
|
|
returned token contains both the MIC and text of the message. The text of
|
||
|
|
the message is either ciphertext (for an encrypted message) or the original
|
||
|
|
plaintext (for messages that are not encrypted). </p>
|
||
|
|
<p><strong>Using getMIC()</strong></p>
|
||
|
|
<div class="p">The
|
||
|
|
getMIC method performs the following actions but cannot encrypt the message:
|
||
|
|
<ul><li>Computes an MIC</li>
|
||
|
|
<li>Returns a token</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<p>The returned token contains only the computed MIC and does not
|
||
|
|
include the original message. So, in addition to transporting the MIC token
|
||
|
|
to the peer, the peer must somehow be made aware of the original message so
|
||
|
|
that it can verify the MIC. </p>
|
||
|
|
<p><strong>Example: Using per-message services
|
||
|
|
to send a message</strong></p>
|
||
|
|
<div class="p">The following example shows how one peer (foo)
|
||
|
|
can wrap a message for delivery to another peer (superSecureServer): <pre> byte[] message = "Ready to roll!".getBytes();
|
||
|
|
MessageProp mprop = new MessageProp(true); // foo wants the message encrypted
|
||
|
|
byte[] wrappedMessage =
|
||
|
|
fooContext.wrap(message, 0, message.length, mprop);
|
||
|
|
send(wrappedMessage); // transfer the wrapped message to superSecureServer
|
||
|
|
|
||
|
|
// This is how superSecureServer may obtain a MIC for delivery to foo:
|
||
|
|
byte[] message = "You bet!".getBytes();
|
||
|
|
MessageProp mprop = null; // superSecureServer is content with
|
||
|
|
// the default quality of protection
|
||
|
|
|
||
|
|
byte[] mic =
|
||
|
|
serverAcceptorContext.getMIC(message, 0, message.length, mprop);
|
||
|
|
send(mic);
|
||
|
|
// send the MIC to foo. foo also needs the original message to verify the MIC</pre>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Receiving messages</h4><p>The receiver of a wrapped message
|
||
|
|
uses unwrap() to decode the message. The unwrap method performs the following
|
||
|
|
actions:</p>
|
||
|
|
<ul><li>Verifies the cryptographic MIC embedded in the message</li>
|
||
|
|
<li>Returns the original message over which the sender computed the MIC</li>
|
||
|
|
</ul>
|
||
|
|
<p> If the sender encrypted the message, unwrap() decrypts the message
|
||
|
|
before verifying the MIC and then returns the original plaintext message.
|
||
|
|
The receiver of an MIC token uses verifyMIC() to verify the MIC over a given
|
||
|
|
a message.</p>
|
||
|
|
<p>The peer applications use their own protocol to deliver JGSS
|
||
|
|
context and message tokens to each other. Peer applications also need to
|
||
|
|
define a protocol for determining whether the token is an MIC or a wrapped
|
||
|
|
message. For example, part of such a protocol may be as simple (and rigid)
|
||
|
|
as that used by Simple Authentication and Security Layer (SASL) applications.
|
||
|
|
The SASL protocol specifies that the context acceptor is always the first
|
||
|
|
peer to send a per-message (wrapped) token following context establishment. </p>
|
||
|
|
<p>For
|
||
|
|
more information, see <a href="http://www.ietf.org/rfc/rfc2222.txt" target="_blank">Simple Authentication and Security Layer (SASL)</a>.</p>
|
||
|
|
<p><strong>Example:
|
||
|
|
Using per-message services to receive a message</strong></p>
|
||
|
|
<div class="p">The following examples
|
||
|
|
shows how a peer (superSecureServer) unwraps the wrapped token that it received
|
||
|
|
from another peer (foo): <pre> MessageProp mprop = new MessageProp(false);
|
||
|
|
|
||
|
|
byte[] plaintextFromFoo =
|
||
|
|
serverAcceptorContext.unwrap(wrappedTokenFromFoo, 0,
|
||
|
|
wrappedTokenFromFoo.length, mprop);
|
||
|
|
|
||
|
|
// superSecureServer can now examine mprop to determine the message properties
|
||
|
|
// (such as whether the message was encrypted) applied by foo.
|
||
|
|
|
||
|
|
// foo verifies the MIC received from superSecureServer:
|
||
|
|
|
||
|
|
MessageProp mprop = new MessageProp(false);
|
||
|
|
fooContext.verifyMIC(micFromFoo, 0, micFromFoo.length, messageFromFoo, 0,
|
||
|
|
messageFromFoo.length, mprop);
|
||
|
|
|
||
|
|
// foo can now examine mprop to determine the message properties applied by
|
||
|
|
|
||
|
|
// superSecureServer. In particular, it can assert that the message was not
|
||
|
|
|
||
|
|
// encrypted since getMIC should never encrypt a message.</pre>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzahajgssdev10.htm" title="There are multiple steps required to develop a JGSS application, including using transport tokens, creating the necessary JGSS objects, establishing and deleting context, and using per-message services.">IBM JGSS application programming steps</a></div>
|
||
|
|
<div class="previouslink"><strong>Previous topic:</strong> <a href="rzahajgssdev1060.htm" title="The two communicating peers must establish a security context over which they can use per-message services.">Establishing context</a></div>
|
||
|
|
<div class="nextlink"><strong>Next topic:</strong> <a href="rzahajgssdev1080.htm" title="A peer deletes a context when the context is no longer needed. In JGSS operations, each peer unilaterally decides when to delete a context and does not need to inform its peer.">Deleting context</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|